With the advent of 5.00.8239.1000, the site had a major build upgrade (as opposed to a minor build change a la hotfix) and yet another client update to rollout. Normally I would do a client push and slipstream in the client MSI using the clientpatch hack here.
Quite frankly, I was getting a bit tired of pushing the client over the course of a month 😀
So I decided to investigate something that had been bugging me for a while: Automatic Client Upgrade, and why the option was greyed out to enable it was greyed out.
I believe this is a new, as in new to Config Manager 2012, option. We still have the tradition client deployment options either as an automated Client Push or as a Software Update based installation:
As a side note, I setup my site to run with a Software Update based installation. It’s rather marvelous, and nicely captures all the rogue IT bods who just dump a machine into the domain without following due process. Anyway, I digress..
Go into the site hierarchy settings, like so:
Click on the sites entry under Site Configuration, and click on Hierarchy Settings from the ribbon at the top. Now click on the Automatic Upgrade tab.
It’s a fairly straight forward set of options. However they were all greyed out. I did a quick search and found this excellent post by the ubiquitous Kent Augerland:
So I updated the Security Scopes, and this made an instant change. I ticked the box, and changed the default period from one day to seven days.
The day count is interesting. I was quite wary of a massive wave of installs slamming the site but this allows a grace period of x to y number of days for the install to be scheduled by the client. This staggers things nicely.
There are a few gotchas, as ever, to be aware of.
Firstly the install is scheduled on all PCs, even if they already up to date. This suggests the underlying technology is closely related to the Client Push option, which has the same behaviour. This is a bit of a disappointment, as you can see the client is aware of the future scheduled upgrade, so surely it could make a decision not to do so… perhaps a tick box along the lines of “Hey dude. Don’t upgrade clients that are already upgraded” would be helpful *cough*.
Also, if you’ve done the erstwhile clientpatch slipstreaming hack, don’t forget to remove the clientpatch stuff or it will still refer to it in the logs. It’s not a problem, it just looks messy to have the client referring to a hotfix which is no longer applicable (and needlessly downloading it to the client). Perhaps this is why Microsoft don’t support it.
Finally, and perhaps most prominently, you will have kittens if you take an unprepared look at the Client Deployment Failure Report courtesy of your Fallback Status Point (You *do* have a FSP, right?).
Yes, for some reason whenever the Automatic Client Upgrade is scheduled on a PC, it returns a failure to the FSP. Why? I can honestly say that, after ticking the box, I nearly soiled myself when I later looked at the report.
The log snippets are all I have to go on:
- <!–[LOG[ITaskService::GetFolder failed with 0x80070003]LOG]!>
- <!–[LOG[<ClientDeploymentMessage ErrorCode=”0″>]LOG]!>
- <!–[LOG[CcmSetup is exiting with return code 0]LOG]!>
Perhaps it’s the 0x80070003 error, although the client does subsequently return a code 0 and does clearly schedules the update.