Client Push Account Settings Bug
Yesterday I finally opened up my SCCM server that I have been building to clients. I created a special Active Directory OU to put computers in so that I could control discovery at the beginning of my deployment. Ran AD System Discovery on the OU which pulled the systems into SCCM. I had already configured the “Client Push Installation” settings, and had added a client push installation account.
When I pushed to a workstation, it failed. In looking through the ccm.log file, I saw the following entries:
Begin Processing request: “GWLDBUKF”, machine name: “workstation”
Trying each entry in the SMS Client Remote Installation account list
Attempting to connect to administrative share ‘\\workstation.domain.com\admin$’ using account ‘í³a‘<‘
WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account í³a‘< (0000052e)
LogonUser failed (LOGON32_LOGON_INTERACTIVE) using account í³a‘< (0000052e)
Attempting to connect to administrative share ‘\\workstation.domain.com\admin$’ using machine account.
Connected to administrative share on machine workstation.domain.com
Attempting to make IPC connection to share <\\workstation.domain.com\IPC$>
Searching for SMSClientInstall.* under ‘\\workstation.domain.com\admin$\’
CWmi::Connect(): ConnectServer(Namespace) failed. – 0x800706ba
Unable to connect to WMI on remote machine “workstation”, error = 0×800706ba.
Deleting SMS Client Install Lock File ‘\\workstation.domain.com\admin$\SMSClientInstall.XYZ’
Retry request id for “GWLDBUKF” set to “workstation_domain_com”
Stored request “workstation_domain_com”, machine name “workstation”, in queue “Retry”.
End request: “workstation_domain_com”, machine name: “workstation”.
In particular note the account name that it tried in the first “Attempting to connect…” line…it’s not valid…basically gibberish. After trying a few things, I remembered an issue I ran into with SMS 2003. In one of the settings…I can’t remember which…maybe the Network Access account…the password field would enable you to enter a password longer than what it could actually handle. That may not make sense now…I’ll explain shortly.
So, I changed the password for my Client Push Account (both in AD and by deleting and adding afresh in the Client Push Installation settings). I made it significantly shorter than what I normally use for what is essentially a service account. [Side Note: since Service Accounts do not often…if ever…have their passwords changed, I always make them extra long. Considering that my regular password is somewhere between 25-35 characters long…extra long is more than that. In this case I was using a 47 character password for the Client Push Account.] I shortened the password to twelve characters, and everything worked as it should.
So, I decided to do a bit of trial and error. I added one new computer at a time to my discovery OU…changed the push account password…ran discovery…then attempted to install the client. 24 characters worked. 36 characters worked. 47 did not work. 46, 45, 44, 43, 42, 41, 40, 39, 38…BINGO! In hindsight, I should have tried 40 after 36…it would have shortened my process.
Using a password longer than 38 characters caused the client push install process to choke. Remember that line in the log above?
Attempting to connect to administrative share ‘\\workstation.domain.com\admin$’ using account ‘í³a‘<‘
Once I lowered the password to 38 characters, this is what that line looks like
Attempting to connect to administrative share ‘\\workstation.domain.com\admin$’ using account ‘domain\clientpushaccountname’
I remember running into a similar issue with the Network Access Account in SCCM. I have confirmed that the “Computer Join Account” and the “Image Upload Account” (both used in Operating System Deployment) do not have this limitation. A similarly long password worked fine for both of them.
So…this seems to be a bug in SCCM. It should be able to handle any valid Active Directory password…which I think is a maximum of 127 characters. Another alternative (bad alternative in my opinion) would be for the password field where you set the Client Push Account to not accept more than X amount of characters. I will be reporting this to the SCCM product team for them to investigate.
I do wonder…I came up with a 38 character limitation. When you enter the account name, it goes in as “domain\account”. My domain name is three characters long, and the account name was nineteen characters. I wonder if the maximum password length is different if the domain name and account name are different lengths. I wouldn’t think so, but who knows?
Key thing is…be aware that there is a limitation. If you are seeing gibberish for the account name…try lowering the password length.
[Update: I did submit this as a bug, and got a response back from Wally Mead that the dev team calls it a limitation instead of a bug. Essentially it is a limitation of the encryption process that has not been updated. They are going to update that in a future update to SCCM. While technically this is in fact a limitation instead of a bug, when a limitation is not documented, it sure looks, acts and smells a lot like a bug! ]
3 Comments »
Leave a Reply
Subscribe
Recent Comments
-
The Realm of the Verbal Processor 
I have the same problem but I just having 12 character long password.
I heard something that a local account must be setup on the client machine?
No, a local account doesn’t need to be set up on the client machine, although the Client Push Account does need admin rights on the client machine…which can be accomplished via Group Policy.
If your account is showing up as gibberish, I’m wondering if you have any special characters in your account name (or password for that matter)? It’s possible that something like that could cause the same type of results. I know I’ve seen that when using a batch file to change the local admin password on a machine…it didn’t like me using an “&” in the password, but was completely fine with me using “@”. That’s a long shot, but worth exploring.
In response to clubber’s comment, I was talking this issue over with a friend this week, and he mentioned that there is also an issue if that password has a space in it. I have not confirmed this, but he is someone that I typically trust his comments without confirming them on my own. So…perhaps the password has a space in it that the process is gacking on. Just a thought. (And actually, that is just another flavor of the special character thing I mentioned in my first comment.)