Where can I find that GPO setting?

Is there a policy for that? Would that be a computer based policy or a user based policy? If I can’t set that with a traditional group policy can I do it with a preference? When dealing with Group Policy Objects (GPOs) I find myself asking these types of questions all the time? Wouldn’t it be nice if there was a searchable site of policy settings? Sure you can Google settings and there are great sites such as www.gpanswers.com but I’m talking about a site that allows you to search for group policy settings, identifies where you can set them, explain what they do and most importantly what registry settings they touch.  There is. MSDN publishes a site that does this. Group Policy Search is a fantastic resource when dealing with group policies. When you search for setting the tool will provide you with the following information:

• Policy Name
• Category Path (Where you can find it in the console)
• Supported Platforms (What the minimal operating system level required)
• Registry Key
• Value
• Explanation of what the policy does

If you’re like me and deal regularly with group policy administration you’ll find this tool a huge time saver. And yes it has just been updated for Windows 8 and Windows Server 2012

WMI and the ConfigMgr Client

If you still manage Windows XP machines with ConfigMgr I’m sure that you know that 9 out of 10 client health issues are WMI related. Whether it’s the CCM namespace getting corrupt or the entire WMI repository getting corrupt... Windows XP WMI + ConfigMgr = unstable.
Most of the time you can get away with simply deleting the ccm namespace and then reinstalling the ConfigMgr client to correct the problem. (More on that later) However there are times when the fix requires you to rebuild the entire WMI repository – which should be used as a last resort as there could be other applications on the machine that rely on WMI.
After searching around for WMI resources I came across this post which does a great job of detailing different ways to resolve your WMI issues based on your Operating System version. I've used many of these approaches in order to resolve client health issues but I’ve had the most success with the following command:

• From a command prompt run rundll32 wbemupgrd, RepairWMISetup

If you decide that rebuilding the WMI repository is what you need to do follow these steps for Windows XP:

• Open a command prompt and run the following
• net stop winmgmt
• Browse to %windir%\System32\Wbem
• Rename the Repository folder
• Go back to your command prompt and run the following to rebuild your repository
• net start winmgmt

As mentioned before, If you rebuild your WMI repository you run the risk of breaking other applications on that machine that require WMI. A safer method is to simply delete the CCM namespace and then repair the ConfigMgr client. One tool that I now use almost exclusively is SCCM Client Center. SCCM Client Center allows you to do a variety of things but one of the most handy options are it’s client repair options. After you install Client Center connect to the machine in question, (Top left-hand corner) click on the Agent Action menu (highlighted in the screen shot below) and as you can see there are a bunch of actions that you can kick off to repair the ConfigMgr client. Most of the time selecting Delete root \ccm will resolve your problem.



I find myself using this tool everyday for a variety of reasons.

Task Scheduler Does Not Save Network Credentials

Whether it’s PCI, HIPAA, CSOX or another compliance program that effects your organization, server hardening is most likely part of the program. Its one thing to provision a hardened server and then get you application installed and working correctly – your server’s behaviour doesn’t change after it’s provisioned. However when the hardening settings are pushed out post production the server’s behavior may change where things that once worked no longer do. For example recently I had an issue where a scheduled task on one of my servers would no longer store the network credentials of the service account that was running the job. What once worked, no longer did.

After a little digging I found that a security setting on the box had been updated. The following setting, Network access: Do not allow storage of credentials or .NET Passports for network authentication had been changed from disabled to enabled in the local security policy. For more information on this setting check out TechNet. Once this setting was reverted back to the default setting the scheduled task get be set to use a domain service account.

PowerPoint causes 100% CPU usage in a seamless XenDesktop session

For last couple of days I’ve been trying to determine the root cause of a problem that I was having with PowerPoint and XenDesktop. The scenario was a Windows XP workstation with Office 2010 being launched in a seamless XenDesktop 5.0 SP1 session on a dual monitor machine. Whenever I opened PowerPoint it would cause Explorer.exe to use 100% CPU and render the virtual machine useless. The issue did not occur if I started PowerPoint in safe mode. After much trial and error and countless searches online I came across the following Citrix article that was just published – CTX132436. It’s not the exact setup that I had but it did bring to attention the Disable hardware graphics acceleration setting in the Advanced options of PowerPoint. Once I enabled this option PowerPoint could open in a seamless session without pinning the CPU. 

This setting is a per-user setting so you will need to apply it to every user that logs on. To deploy this via GPO you will need to download the Office 2010 ADM, ADMX/ADML files from here. Once you have downloaded and installed them, (Note if you use ADM files you’ll need to add them to your policy using Add/remove Templates from within the GPO) open your GPO editor

• Navigate to User Configuration\Policies\Administrative Templates\Microsoft Office 2010\Miscellaneous
• Set Do not use hardware graphics acceleration to Enabled

ConfigMgr Reports Prompts for a Password

Out of the blue my web reporting for ConfigMgr started prompting for a password and no matter what account you entered it would be rejected. If you cancelled the prompt you would receive an access denied error. My reporting site was setup properly with all of the correct prerequisites as it had been online for a couple of years. Nothing seemed to work – no recent patches had been installed, logs were clean, permissions looked correct, IISRESET didn’t nor did a system reboot. Reports would also work fine from a local session on the site server. After much digging I finally came across a post on the TechNet forums that resolved the issue. Here are the steps that helped resolve the issue:

·         Open IIS Manager and navigate to your SMS_Reporting site

·         Click on the site and select Authentication under IIS from the main screen

·         From the Action pane select Providers

·         Ensure the NTLM is listed and it is at the top of the list

·         Open a command prompt and run IISRESET

After that I could access reports locally and from a remote session. All the more reason to migrate my ConfigMgr reporting to SQL Reporting Services.

PXE test request failed, status code is -2147467259, Error receiving replies from PXE server

Recently OSD on my primary site server stopped working – but only when connecting via PXE. If I was using an existing boot disk, I could connect and start the imaging process. The PXE control log had the following entry over and over:

“PXE test request failed, status code is -2147467259, Error receiving replies from PXE server”

I assumed that the Windows Deployment Services Server (WDS) service had stopped and all I had to do was restart it and it would start responding to PXE requests. I was correct on one thing, the WDS service had stopped however when I tried to restart the service I got a very similar error in the event viewer as references in this forum post:

Log Name: System
Source: Service Control Manager
General: The Windows Deployment Services Server service terminated unexpectedly.  It has done this 2 time(s).  The following corrective action will be taken in 600000 milliseconds: Restart the service.

Log Name: Application
Source: Application Error
General: Faulting application name: svchost.exe_WDSServer, version: 6.1.7600.16385, time stamp: 0x4a5bc3c1
Faulting module name: wimgapi.dll, version: 6.1.7600.16385, time stamp: 0x4a5be09a
Exception code: 0xc0000005
Fault offset: 0x0000000000032a8e
Faulting process id: 0x1338
Faulting application start time: 0x01cbfecfb154f4f3
Faulting application path: C:\Windows\system32\svchost.exe
Faulting module path: C:\Windows\system32\wimgapi.dll
Report Id: f089f975-6ac2-11e0-9ddc-005056970055

After rebooting the server the same error was logged and WDS would not start. Even after removing the boot image from my distribution points and then adding them back - WDS would still not start. I tracked them problem down to recent driver addition to the WinPE boot image. It looked like when ConfigMgr was recompiling the WIM file it corrupted the image. To resolve this issue I did the following:

·         Remove the boot image from all distribution points (monitoring the distmgr log file)

·         Removed all drivers from the WinPE image

·         Added all our drivers back to the image and allowed it to recompile

·         Added the boot image back to the distribution points (monitoring the distmgr log file)

·         When everything had replicated successfully I was able to restart the WDS service