Microsoft have now released CU3 for ConfigMgr 2012 R2 and further details can be found from the following link
http://support.microsoft.com/kb/2994331/
The key update is the option for a workaround to the MP rotation cycle via a registry value
Every seen this before?????
Fairly common issue when you have an unsuspecting GPO in your environment taking some precendence over ConfigMgr. Well what if you dont have one????
Working on a piece of work for a client who had around 3% of their clients reporting as ‘Compliance Unknown’ and this error was reported in WUAHandler.log
After ruling out anything to do with ConfigMgr and a Group Policy applying it turned out that there was a ‘jammed’ GPO policy on the end client which was resolved by deleting the following file:
C:\Windows\System32\GroupPolicy\Machine\Registry.pol
As this was a machine setting after this was cleared and the machine restarted to force a policy update from a DC, the next time a Software Update Scan was initiated the Software update cycle began and on the Software Evaluation cycle the updates began to install!
Quite often when working on Software Updating projects I am aiming to bring compliance up quite quickly inside a change windows and need to leverage the abilitly to quicken the agents poll for certain actions. Most of the common tasks can be placed in a program and deployed out to machines rather than initiating these steps manually.
An example of initiating a Software Update scan is below:
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “{00000000-0000-0000-0000-000000000113}” /NOINTERACTIVE
There are a number of additional triggers which can be interchanged into the above command.
{00000000-0000-0000-0000-000000000001} Hardware Inventory
{00000000-0000-0000-0000-000000000002} Software Inventory
{00000000-0000-0000-0000-000000000003} Discovery Inventory
{00000000-0000-0000-0000-000000000010} File Collection
{00000000-0000-0000-0000-000000000011} IDMIF Collection
{00000000-0000-0000-0000-000000000012} Client Machine Authentication
{00000000-0000-0000-0000-000000000021} Request Machine Assignments
{00000000-0000-0000-0000-000000000022} Evaluate Machine Policies
{00000000-0000-0000-0000-000000000023} Refresh Default MP Task
{00000000-0000-0000-0000-000000000024} LS (Location Service) Refresh Locations Task
{00000000-0000-0000-0000-000000000025} LS (Location Service) Timeout Refresh Task
{00000000-0000-0000-0000-000000000026} Policy Agent Request Assignment (User)
{00000000-0000-0000-0000-000000000027} Policy Agent Evaluate Assignment (User)
{00000000-0000-0000-0000-000000000031} Software Metering Generating Usage Report
{00000000-0000-0000-0000-000000000032} Source Update Message
{00000000-0000-0000-0000-000000000037} Clearing proxy settings cache
{00000000-0000-0000-0000-000000000040} Machine Policy Agent Cleanup
{00000000-0000-0000-0000-000000000041} User Policy Agent Cleanup
{00000000-0000-0000-0000-000000000042} Policy Agent Validate Machine Policy / Assignment
{00000000-0000-0000-0000-000000000043} Policy Agent Validate User Policy / Assignment
{00000000-0000-0000-0000-000000000051} Retrying/Refreshing certificates in AD on MP
{00000000-0000-0000-0000-000000000061} Peer DP Status reporting
{00000000-0000-0000-0000-000000000062} Peer DP Pending package check schedule
{00000000-0000-0000-0000-000000000063} SUM Updates install schedule
{00000000-0000-0000-0000-000000000071} NAP action
{00000000-0000-0000-0000-000000000101} Hardware Inventory Collection Cycle
{00000000-0000-0000-0000-000000000102} Software Inventory Collection Cycle
{00000000-0000-0000-0000-000000000103} Discovery Data Collection Cycle
{00000000-0000-0000-0000-000000000104} File Collection Cycle
{00000000-0000-0000-0000-000000000105} IDMIF Collection Cycle
{00000000-0000-0000-0000-000000000106} Software Metering Usage Report Cycle
{00000000-0000-0000-0000-000000000107} Windows Installer Source List Update Cycle
{00000000-0000-0000-0000-000000000108} Software Updates Assignments Evaluation Cycle
{00000000-0000-0000-0000-000000000109} Branch Distribution Point Maintenance Task
{00000000-0000-0000-0000-000000000110} DCM policy
{00000000-0000-0000-0000-000000000111} Send Unsent State Message
{00000000-0000-0000-0000-000000000112} State System policy cache cleanout
{00000000-0000-0000-0000-000000000113} Scan by Update Source
{00000000-0000-0000-0000-000000000114} Update Store Policy
{00000000-0000-0000-0000-000000000115} State system policy bulk send high
{00000000-0000-0000-0000-000000000116} State system policy bulk send low
{00000000-0000-0000-0000-000000000120} AMT Status Check Policy
{00000000-0000-0000-0000-000000000121} Application manager policy action
{00000000-0000-0000-0000-000000000122} Application manager user policy action
{00000000-0000-0000-0000-000000000123} Application manager global evaluation action
{00000000-0000-0000-0000-000000000131} Power management start summarizer
{00000000-0000-0000-0000-000000000221} Endpoint deployment reevaluate
{00000000-0000-0000-0000-000000000222} Endpoint AM policy reevaluate
{00000000-0000-0000-0000-000000000223} External event detection
These can be placed in a program and deployed to your clients.
After spending a large portion of the last two days troubleshooting some MSI installations while I continue to teach myself Software Packaging in the right way!, I came across a number of my MSI’s which were simply not running Active Setups correctly. They seem to not put in HKCU which when run in GUI were producing an error message:
Error 123: The filename, directory name or volume label syntax is incorrect.
When this was logged out with MSI Verbose logging, the options I was using were msiexec /fup also produced an error complaining about SECREPAIR Hash Issues pulling down from the ConfigMgr DP. This behaviour was also witnessed when running a repair from Add/Remove Programs.
After spending alot of time looking at my 2012 Environment which I have built at least 20 times for different clients it turns out that in August 2014, Microsoft released an update for Windows Installer which has a known issue for how it handles Secrepair CryptAcquire for MSI’s. The result of this update is the impact talked about in this article.
By removing this update (KB2918614) all of my MSI repairs returned to their normal working state of referencing the locations on ConfigMgr DP.
I am not sure how widespread the issue is as it was difficult to get any information on but after spending a considerable amount of time on this, if I can help anyone else something good will have come from this 🙂
So often when interviewing or working with colleagues I often hear the question:
‘What is the best log file to look in if Updates are not deploying via ConfigMgr to clients????’
Well the answer is there is not just one. A number of log files work together to reflect the process of updates deploying and a few key ones I use are below:
Wsyncmgr.log
WUAHandler.log
Wsusctrl.log
WCM.log
Along with
Datatransfer.log
CAS.log
Often the issue will lie somewhere within these logs if the issues is specific to update deployment.
There is still the standard windowsupdate.log but I find the above are more granular where the issue lies if a problem was to occur!
Working at a client site this week after retuning for a health check I noticed that the SQL Server Log drive for SRS had consumed almost all of the disk available at 30GB!!!
Now as we know the logs for SRS should not be anywhere near that and trying to shrink down the available space proved fruitless as SQL was complaining about the disk being full. The auto grow was configured to consume all disk so this could not be amended easily.
As an Interim measure the recovery model on the database was set to Full which once changed to Simple allowed the database shrink to be implemented and corrected thus preventing SQL from consuming all of the disk.
Now the auto grow can be amended and if required recovery model reverted back to full.
The Configuration Manager Product team have now released CU2 for ConfigMgr 2012 which can be downloaded here . A list of bug fixes is also included.