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.
I recently upgraded to MDT Update 2 integrated with SCCM 1602. Previously I used to install Windows 7 using MDT UDI (2013 I think?) and configured the OSDJoinDomain and OSDJoinPassword variables as collection variables on the collections I had the task sequence. But after the 2013 update 2 install, on my new task sequence for Windows 10 they would show up like the below and it wouldn’t join the domain.
So thanks to some help on this TechNet forum we were able to come up with a workaround.
- Create two custom variables and place them just before the UDI Wizard step in your task sequence. One will be the account used to join the domain and the other the accounts password.
- Then open up the UDI Wizard Designer and on the new computer details page under “domain join credentials” put in the custom variables you setup into the default value boxes (remember to use %% around your task sequence variables).
- Then simply save your changes and update your MDT Toolkit package in SCCM. Then you should be all set.
Well I finally got a good image of Windows 10 with my custom settings yesterday so now it was on to iron out my deploy task sequence for SCCM integrated with MDT 2013. I was working on getting my existing UDIWizard_Config.xml files from my MDT 2013 toolkit files for Windows 10 to work with MDT 2013 Update 2. Why create an entire new file when you can simply reuse my wizard settings as I have a lot of custom settings for OU’s and such. It seemed that no matter what I did it held onto the old settings and wouldn’t update. Finally through a mention in a technet forum I discovered that the applications in the install programs page in the wizard caused it to fail and use the old UDIWizard_Config.xml from before. So I simply deleted all my software in the wizard and re-validated the site settings with configuration manager and then went in and clicked update distribution points. Eureka, upon pxe booting all my new settings were there. Goes to show what I get for reusing UDI Wizard settings. So yes you can reuse your UDI wizard settings from previous MDT Versions but proceed with caution.