Happy Friday everyone, I can’t take any credit at all for this one but someone (much better at Powershell than me) has wrote this amazing script on removing updates that are not deployed or not required on any machines but are still in a deployment package. This is been something I’ve needed for a long time to save disk space on DP’s.
See link below.
Happy Wednesday, (Well as happy as an Wednesday can be I guess…) I was prompted by a user that their machine was behind on updates as were many others as they tried updating from the web and got lots of updates. I did some checking and all the updates looked to be fairly recent within the last month but were listed as Critical level updates. This confused me as I have critical level updates deploying more often than once a month to not get behind on security vulnerabilities as Microsoft patches them. After some research I realized there is a difference between Critical level severity and Critical level update classifications. Microsoft defines Critical Updates as “A widely released fix for a specific problem that addresses a critical, non-security-related bug.” So just because it’s in the critical update classification it may not have an severity level of critical. In fact critical level updates have a severity of none as they are not related to security. So critical severity updates are security only. Critical update classification is non security updates. The critical severity level updates fall into the security update classification. So if your like me and push out critical severity security updates more often than your other updates don’t start thinking SCCM isn’t working since you got confused between Update classifications and Severity levels. Found my answer on the technet forums as someone else was confused like I was. Happy Updating.
Technet Forum post referenced https://social.technet.microsoft.com/Forums/en-US/e55aa1bc-648e-480d-91eb-828ca5b52f73/critical-updates-with-none-as-a-severity-do-not-get-pushed?forum=configmanagersecurity
I had a Lenovo x240 laptop that wouldn’t image. Other machines would image just fine so I did what any decent SCCM admin would do I looked at the smsts.log and found an error something like 0x80091007 indicating a hash mismatch between the DP and the WIM on the machine. Normally when this occurs the normal recommendation is to refresh the DP with a new copy of the WIM to make sure the DP doesn’t have a bad copy from the main SCCM server but as other pc’s were imaging fine off the same DP it had to be either with that specific machine or something with that model of PC’s. After digging and getting nowhere I stumbled on this article from thespoo.blogspot.com detailing all the way back in 2010 how a bad ram stick could cause the hash mismatch. So I replaced the RAM and sure enough, it was fixed and I was on its way. Goes to show sometimes the simple things can be the fix. I was looking for something a little more elaborate.
I had an issue the other day with an application not installing that I had been installing for a long time through the UDI wizard with the MDT Integration with SCCM 2012. Suddenly it had stopped installing and I got the below error in the SMSTS.log.
Make sure the application is marked for dynamic app install Policy download failed, hr=0x80004005. The operating system reported error 2147500037: Unspecified error
While this error can be caused by symbols such as a comma or ampersand in the application name for me it was because I had changed the application name to a more user-friendly name which in turn broke the UDI as it doesn’t dynamically update application names. I simply went into the UDI and removed and re-added the application and it started working again.