ConfigMgr 2007 R3 Client Hotfix Shenanigans

I’ve been spending some time recently resolving some issues I encountered getting clients in a new estate running the ConfigMgr 2007 R3 hotfix.  In a customer environnment that contained multiple DNS domains, Active Directory domains at various trust levels and a non-functional WINS environment we are heavily reliant upon the SLP role and having the SMSSLP client setting in Client Push.  I found that the default R3 client install totally wipes out the SMSSLP settings at the client leaving you with upgraded clients that can’t talk back!  You wouldn’t necessarily spot this if clients can find their MP using either AD, DNS or WINS.

So a word of warning to you that before rolling out the R3 client hotfix program you may need to add in your switches for  SMSSLP=server.domain.com and FSP=server.domain.com to the install command line if you have workgroup systems or systems in other domains etc.

If your ConfigMgr client environment does not rely on additional switches there IS an unsupported solution of having the SP2 client installed with the R3 patch using client push all in one go, by including the hotfix within a ‘ClientPatch’ folder where ccmsetup.exe resides.  The hotfix will be automatically detected and downloaded by BITS during client installation and ccmsetup.exe will install and upgrade your client to R3 for you.

Also frustrating is that getting a client to R3 level during a task sequence install isn’t as easy as it should be – the Task Sequence will fail if you try to install it as a Software Package.  The accepted solution requires that you get the patch installed at the same time as the client install within the task sequence ‘Setup Windows and ConfigMgr” step.  Within the Installation Properties you need to add in:

PATCH=”C:\_SMSTaskSequence\OSD\<PackageID>\i386\hotfix\KB977384\sccm2007ac-sp2-kb977384-x86-enu.msp”

…where the PackageID matches your current ConfigMgr client setup files package – but you knew that already.

Andy

ConfigMgr Run Advertised Programs Tool not showing Non-Mandatory User Policies

I’ve been investigating an issue for one of my colleagues where the ConfigMgr 2007 SP1 Run Advertised Program tool isn’t showing some users their Non-Mandatorily assigned Programs.  The SMSCLIUI.LOG shows that the RAP tool should be showing ‘x scripts available’ for the user to run, and PolicySpy confirms that the currently logged in user’s SID has the policies showing in the ‘Requested’ and ‘Actual’ stores – alas, nothing in the RAP Tool.

Interestingly, we found that if the test user logged into a system they had never logged into before (evidenced by lack of the users SID folder in the PolicySpy tool) they would see a couple of machine targeted Non-Mandatory Programs in the RAP Tool – that is until a User Policy Refresh occured and then even those would disappear!

It seems that restarting the SMS Agent Host whilst the user is logged in rectifies this annoying little issue but I’d like to get to the root cause.  After a reboot or logout/login the RAP Tool seems to continue to behave itself and the programs remain visible.  It’s as though the User policies coming down are somehow freaking the SMS Agent Host out and it doesn’t continue with the task of ‘presenting’ them once they’ve arrived.

I’ll no doubt be roped into continuing to look into this issue tomorrow and I’ll think I’ll start with enabling verbose/debuglogging of the SMS Agent Host.

To be continued…

SQL Backup task failed. Error message – SQL Writer not found

In my Virtual Environment the ConfigMgr database has been happily living on another Windows Server 2008 R2 / SQL 2008 R2 server seperate from the ConfigMgr 2008 R2 Site Server and has previously succeeded in performing a site backup.  However today, when I thought I’d perform another backup manually I was greeted with a failure message in the smsbkup.log related to “SQL Writer not found.”

Nothing had changed in my Virtual environment other than the application of SQL 2008 R2 Cumulative Update 4 – which was applied as a possible fix for a SQL Reporting Services error I kept getting.  A quick googling didn’t reveal any decent answer except to give the SYSTEM account SYSADMIN permissions on the SQL Server 2008 server – which whilst not ideal, seems to work for the time being and I can suffer it in a non-production environment.

If you are thinking of applying SQL 2008 R2 CU4, then please test your ConfigMgr backup routine before and after and let me know if this is the culprit!  I’m loathe to roll-back the CU4 given I’ve only just got the SQL Reporting Services Role appeased!

Andy