I had an issue today where a printer would print but the print jobs would just continue to fill up the queue even after clearing them out. I was running server 2008 R2 on this print server so the first thing I tried was the hotfix from here https://support.microsoft.com/en-us/kb/2906850. This applies to Windows 7 and 2008 R2. I wondered if it wouldn’t fix the issue as it has to do with deny permissions on manage documents. I also found a technet issue that referenced that if creator owner rights to manage documents are removed printer issues could occur. Turned out that wasn’t the issue either as Creator Owner were right where they should be. One user in the same forum referenced that his issue was caused by a WSD port being configured for the printer instead of TCP/IP. Sure enough adding the proper TCP/IP port solved the issue. WSD ports are great for home and small environments but I don’t really trust them in an enterprise environment
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.
The above error is fairly well documented by Microsoft but thought I would post about it anyway just in case someone comes across the same issue as me. I had pushed updates out to machines through SCCM and then started getting a handful that Lync/Skype for Business started reporting that Lync had become Skype for Business and that KB3039779 needed to be installed. Evidently, a few machines we had received a newer update which upgraded them but didn’t have this older update. Simply pushing out the missing KB3039779 to the machines missing the update resolved the issue. Update is located here for anyone curious https://www.microsoft.com/en-us/download/details.aspx?id=47056
I was updating a logon script today and realized that for some reason it wasn’t applying to the machine. I ran rsop and gpresult but neither one showed the policy or the logon script. The gpo was filtered to a specific group of users and the user was clearly a member of the group so I was befuddled what was going on. I finally found a Security update KB 3159398 for Group Policy that came out in June that while fixing a dangerous man-in-the-middle attack breaks filtering if Domain Computer group does not have read permissions to the OU. Follow the below steps to fix and your gpo will be working like normal.
- Open up the gpo in group policy management and click the delegation tab.
- Click Add and type in domain computers.
- Set permissions to read as is the default.
- Enjoy your fixed GPO’s!
Link to Microsoft Security update and known issues below.
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.
Today I had an AD administrator create a distribution group and add all the members to it in Active Directory. They needed it enabled in Exchange so I thought easy just go into the EAC (Exchange Administrative Center) and add an existing group. This was the case in Exchange 2007 and 2010 but not in 2013. In order to add an existing group so you don’t have to recreate it from the EAC and add all the users back you go into EMC (Exchange Management Console). Then once in Powershell type in the command below.
Enable-DistributionGroup -Identity “groupnameinAD” -Alias “groupname”
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.