Sunday, 15 April 2012

Hmmm, Changing the WAS and Portal admin users in WP7002 doesn't work :-(

I still haven't got to the bottom of this, but I'm seeing: -

[wplc-validate-user-exists]   Instance attributes (Set 1 of 1):
[wplc-validate-user-exists]     ignoreDuplicateIDs= *** NOT_SPECIFIED ***
[wplc-validate-user-exists]     attribute=[ *** NONE_SPECIFIED *** ]
[wplc-validate-user-exists]     customproperty=[ *** NONE_SPECIFIED *** ]
[wplc-validate-user-exists]     cn="CN=PortalBind,OU=Service"
[wplc-validate-user-exists]     trimSpaces= *** NOT_SPECIFIED ***
[wplc-validate-user-exists] com.ibm.websphere.management.cmdframework.InvalidParameterNameException: ADMF0004E: Invalid parameter name CN for command searchUsers.
[wplc-validate-user-exists]     at com.ibm.websphere.management.cmdframework.provider.AbstractAdminCommand.getParameterMetadata(AbstractAdminCommand.java:1096)
[wplc-validate-user-exists]     at com.ibm.websphere.management.cmdframework.provider.AbstractAdminCommand.isParamReadonly(AbstractAdminCommand.java:1162)
[wplc-validate-user-exists]     at com.ibm.websphere.management.cmdframework.provider

when I run: -

./ConfigEngine.sh wp-change-was-admin-user -DnewAdminId="CN=WASAdminPoc,OU=Service Accounts,OU=Management,DC=ts2,DC=net" -DnewAdminPw=NewPassW0rd -DWasPassword=OldPassW0rd

I'm running WebSphere Portal 7.0.0.2 CF12 on Red Hat Enterprise Linux 6, and the user registry is Microsoft Active Directory 2003.

I''ve dug through the WAS logs, even with tracing enabled, and there's nothing apparent.

I added both the -diagnostics and -debug switches to the ConfigEngine.sh command, but nothing was obvious :-(

I even tried running: -

./UpdateProfile.sh install CF

and: -

./ConfigEngine.sh upgrade-profile

but to no avail.

In the end, I "cheated" by adding: -

-Dskip.ldap.validation=true

to the end of the command: -

./ConfigEngine.sh wp-change-was-admin-user -DnewAdminId="CN=WASAdminPoc,OU=Service Accounts,OU=Management,DC=ts2,DC=net" -DnewAdminPw=NewPassW0rd -DWasPassword=OldPassW0rd

Having done this, the command ran through OK.

However, I'm still not sure why it failed int he first instance, and what: -

ADMF0004E: Invalid parameter name CN for command searchUsers.

actually means.

:-(

3 comments:

Dave Hay said...

This from a friend via email - haven't had a chance to try it yet ....

i don't know if it could help ...
But maybe you can take a look at this doc:
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/MultipleRealms.pdf/$file/MultipleRealms.pdf
page 8 - from step 6
the author does a manual change in wkplc.properties for the vars newAdminId and newAdminPw
and then it doesn't pass any parameter during the execution of wp-change-was-admin-user

Hope this helps !

cheers

lshake said...

Hey Dave.

Thanks for the heads up on skip.ldap.validation.

I've just encountered what I hope is a similar problem with Portal8 and a Samba4 LDAP server. Same error, but validating the portal admins group. From what I can tell it doesn't even search for the group on the ldap server so ConfigEngine has decided that the group is invalid itself. Appears to have worked by skiping the validation.

Lee.

Dave Hay said...

Interestingly, I hit the same problem again today, using WP 7.0.0.0 and Domino 8.5.3 LDAP.

I did try setting newAdminId, newAdminPw and newAdminGroupId in wkplc.properties, but to no avail.

I then read this Technote: -

Changing Portal administration users fails with ADMF0004E: Invalid parameter name CN for command searchUsers

http://www-01.ibm.com/support/docview.wss?uid=swg21605247

which was published in July 2012 ( two months after my original post ).

That suggested that the problem was due to: -


...
WebSphere Portal invokes the WebSphere Application Server (WAS) management framework when running either the wp-change-was-admin-user or wp-change-portal-admin-user configuration tasks. The WAS management framework is unable to process users or groups that begin with an uppercase "CN" in their full distinguished name.
...


I tried this, using: -

./ConfigEngine.sh wp-change-portal-admin-user -DnewAdminId=cn=padmin,O=ibm -DnewAdminPw=passw0rd -DnewAdminGroupId=cn=padmins

instead of: -

./ConfigEngine.sh wp-change-portal-admin-user -DnewAdminId=CN=padmin,O=ibm -DnewAdminPw=passw0rd -DnewAdminGroupId=cn=padmins

and, this time, saw "BUILD SUCCESSFUL", which is very nice.

The moral of the story ? Avoid capitalisation of the admin user's Distinguished Name.