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 came across a TechNet blog post on Microsofts site the other day that taught me something new I thought I would pass along in case it would help someone out. If you don’t have software assurance with Microsoft but are a volume license customer you can deploy volume license media providing you have keys and the edition of the OEM OS and the Volume License match. This means you don’t have to be purchasing volume licenses to reimage provided you do have at least a few volume licenses of the software you are trying to deploy. The below blog posts provide more info. Guess you learn something new every day.
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.
Just a quick note incase someone else is having this issue. I was working on using SCCM to image a Dell 7710 laptop and it has a Samsung M.2 PCIe NVMe SSD which I couldn’t seem to ever find the right storage drivers to get it to see the hard disk. It was a one time deal so I resorted to having the onsite tech manually load the machine (which was an endeavor in itself as he had to find the right storage driver to load windows 10 and if you wanted to do windows 7 you had to have USB 3.0 drivers slipstreamed into the windows installer). Upon trying to image another machine pxe would stop part way and display the below error message.
Info: Windows failed to load because a critical system driver is missing, or corrupt
Turned out just like it says nvme drivers I had loaded caused it to completely not load the pxe boot image which I hadn’t seen occur before in adding drivers to a boot image. Pretty straight forward but figured it might help someone that gets this error especially if you didn’t add the drivers or forgot that you had added them.
Good morning, I was working on a scheduled task that would run on a user’s PC and start a particular application when the user logged into their machine and it had to run as the user in particular logging in. What I discovered was that if the user wasn’t administrator on the box I would get an access denied in both PowerShell and schtasks.
What I figured out was that if you choose to run the task at logon (I assume this probably applies to at startup as well) it requires administrative rights but if you schedule the task as an hourly, daily, weekly, etc. task it doesn’t require administrative rights to create it. Now this requires that what the task is running itself doesn’t need administrative rights but in my case it does not.
Now you may be asking yourself why didn’t he simply create a scheduled task through group policy. Well, the reason for that is I wanted it to target a specific computer collection in SCCM that targeted only laptops. I could have done it with a GPO and even filtered the GPO with WMI filtering and accomplished the same thing but the application is pushed out through SCCM and I wanted everything that went with it targeted to that collection. Maybe slightly more work on my part but good to know nonetheless.