Troubleshooting

Tag for posts related to troubleshooting issues and implementing solutions to those issues.

Using Group Policy Preferences with Older Versions of Windows

http://www.microsoft.com/en-us/download/details.aspx?id=6955I was doing some testing with a newly created GPO that used Group Policy Preferences (GPP) to add a user account to the local administrators group, and I noticed that the policy seemed to apply properly to all of my Server 2012 and 2008 systems but not on any Server 2003 machines.

I did some research and came across an article on Microsoft’s Group Policy blog that shined some light on my issue:

Group Policy Preferences Not Applying on Some Clients: Client-Side Extension, XMLLite

The gist of it is that I needed to install the proper Client-Side  Extensions (CSEs) for Server 2003. All of the links for the individual OSes and versions are in the MS blog post, but the specific one I needed is below.

CSEs for Windows Server 2003 with SP1 or later (32-bit)

You may also need to install XMLLite in addition to the CSEs, but to quote the post:

“XMLLite is not needed if:

· Your clients run Windows Server 2008 or Windows Vista.

· Your clients Windows XP and Windows Server 2003 clients run Internet Explorer 7 and/or the latest service packs.”

After installing the CSEs on my machines, they started processing the GPPs normally.

Drop Down

As a side-note for anyone interested; The GPP to add user accounts to local groups is located under Computer Configuration -> Preferences -> Control Panel Settings -> Local Users and Groups.

To modify a local group, right-click and select New – > Local Group, choose Update as the action, pick a group from the Group Name drop down menu, in my case Administrators (built-in) (make sure to use the drop down and not the ellipses button; see image), and then use the Add button at the bottom of the window to add either local or domain accounts to that group.

Most of the guides I’ve found suggest using Computer Configuration\Policies\Windows Settings\Security Settings\Restricted Groups to add users to the local administrators group, but this policy acts to replace any existing memberships rather than merge with them, so keep this in mind if you have Group Policy Objects linked at higher OUs which add users to the same groups. If you want to preserve the existing memberships, consider using GPPs to make the modifications instead.

-Rick

Advertisements

Alt Methods to Fix: “The Trust Relationship Between This Workstation and the Primary Domain Failed”

 

For any Windows admin, this error is a familiar sight.

The typical fix, and Microsoft’s recommended resolution, is to log in with a local admin account, join the system to a workgroup, and then rejoin it to the domain.

However, I ran into this blog post a while back which details some cool alternative methods and saved the link in case it should come in handy some day, which it has on several occasions.

DON’T REJOIN TO FIX: The trust relationship between this workstation and the primary domain failed

Basically, he lists two distinct methods for resetting the computer password:

  1. use netdom.exe

netdom.exe resetpwd /s:<server> /ud:<user> /pd:*

<server> = a domain controller in the joined domain

< user> = DOMAIN\User format with rights to change the computer password

“Where you get netdom.exe depends on what version of Windows you’re running.”

“On Windows Vista and Windows 7 you can get it from the Remote Server Administration Tools (RSAT).”

Download RSAT for Windows 7 SP1 here

Download RSAT for Windows 8.1 here

You can read some additional notes about this method in the blog post. (link here)

  1. via Powershell

Reset-ComputerMachinePassword [-Credential <PSCredential>] [-Server <String>]

“You can use the Get-Credential cmdlet for a secure way to generate a PSCredential, which can be stored in a variable and used in a script.  You will want to generate a credential for an Active Directory user with sufficient rights to change the computer’s password.  The Server parameter is the domain controller to use when setting the machine account password.”

Here’s a TechNet article on the Reset-ComputerMachinePassword command for additional reference.

-Rick

SCCM 2012 R2 Client Installation Fails on Windows Server 2003

http://www.microsoft.com/en-us/download/details.aspx?id=4933

If your environment is like mine, you may be forced to manage some legacy systems with Configuration Manager, some of which may be running older operating systems like Windows Server 2003.

You may also find that the SCCM client refuses to install on Server 2003.

Luckily, the fix is easy enough. The SCCM client requires BITS 2.5 to be installed as a prerequisite. You can download BITS 2.5 for Windows Server 2003 here.

After downloading and installing BITS 2.5 on your Windows Server 2003 systems, you should be able to deploy the SCCM client without a problem.

Sources:

SCCM Not installing 2012 SP1 client on Server 2003 clients

SCCM 2012 and Server 2003×64\XPx64

-Rick

SCCM 2012 R2 – Error When Running Reports – UserTokenSIDS: A Specified logon session does not exist

UserTokenSIDs

 

After installing my SCCM 2012 R2 Primary Site, I attempted to test out the reporting feature and kept running into the following error when trying to run any of the built-in reports:

The DefaultValue expression for the report parameter ‘UserTokenSIDs’ contains an error: a specified login session does not exist. It may already have been terminated.

I did some research and eventually tied it back to my SQL Server Reporting Services (SSRS) configuration.

I have SSRS installed on my primary site server with the reporting database sitting on a remote system running SQL Server 2012,  and when I initially set up SSRS I had it using the Local System built-in account as the service account.

SRSLocal

 

After going back and reviewing the documentation and reading over various blog posts, I realized using Local System as the service account wasn’t going to work and I needed to specify a domain resource account to use with the proper permissions set.

Configuring Reporting in Configuration Manager

Configure a Service Account for Reporting Services

Reporting Services Configuration Manager (SSRS)

So I created a new resource account specifically for SCCM and SSRS, named SMSRS, and made sure to add it to the local SMS Admins group on the site server and grant it sysadmin and remote access permissions to the reporting databases on my SQL server. I then reconfigured the SSRS Service Account and Current Report Server Database Credential settings to use this new SMSRS account.

After restarting the service, I was able to run reports in SCCM without any further trouble.

A few quick additional notes:

  • Before changing the service account for SSRS, be sure to back up the encryption key for the original account so you don’t lose the ability to talk to the existing reporting database.
  • After changing the service account, perform a restore of the backed-up encryption key.

Instructions for backing up and restoring SSRS encryption keys for SQL Server 2012 are here:

Back Up and Restore Reporting Services Encryption Keys

SSRSEncryptionKeys

  • The service account used for SSRS must be a member of the domain local security group Windows Authorization Access Group and have Allow Read tokenGroupsGlobalAndUniversal permissions in Active Directory.

SCCM 2012 R2 Upgrade Breaks SSRS with UserTokenSIDs contains an error

-Rick

SCCM 2012 R2 – Configure Software Inventory

SftInv

Shortly after installing SCCM 2012 R2 and getting the client installed on a few test systems, I noticed that the Inventoried Software section under Assets and Compliance\Asset Intelligence was empty and there was no application information showing up in Resource Explorer. I double checked that I had enabled Software Inventory in my client settings, which I had, so I started doing some research.

Turns out that I was missing two key settings to get what I wanted.

First, I neglected to specify any file types for the SCCM client to include in its software inventory.

Configuration Manager 2012 Software Inventory Missing

I had initially made the assumption that there was a built-in process for discovering installed software and that the “Inventory these file types” setting was only to specify additional file types as needed. As the blog post above suggests, in SCCM 2012 this isn’t the case.  If you don’t explicitly tell the client what to look for, it won’t return any results.

To correct this, I added two wild card entries to the client settings for file types:

  1. *.exe in %ProgramFiles%
  2. *.exe in %ProgramFiles(x86)%

FileTypes

After adding these rules and giving my clients time to get the new settings and run another software inventory cycle, I started seeing results in Asset Intelligence.

However, when I opened up Resource Explorer I found that the only information available under Software was simple file names, paths, and the modified date, among a few other minor file details. Useful, but not quite what I was looking for.

I can’t find the article that I came across now (I’ll try to add it later), but after doing some more research I found  out that you can also add software inventory functionality to the Hardware Inventory pass to get more details about installed applications. Luckily, enabling this was easy enough and just required adding a few additional classes to the hardware inventory client settings.

With Hardware Inventory selected click the Set Classes…. button, which brings up a list of the available items to be included in the hardware inventory. To enable additional software inventory functionality, just check the Installed Applications, Installed Executable, and Installed Software classes from the list.

HardwareInv

After doing this, Resource Explorer now has these new classes available and I’m able to see product GUIDs, version numbers, install dates, file hashes, uninstall strings, and more. Much more useful.

ResEx

-Rick

VMware Horizon View Client Login Fails While Using the “Log in as current user” Option

You may run into this issue when attempting to use the “Log in as current user” option in the VMware Horizon View client. This option allows the user to log in to Horizon View using the currently logged on user’s credentials on Windows clients, so it avoids the need to authenticate twice.

To make a long story short, if “Log in as current user” isn’t working then make sure that your Connection Server’s SYSTEM account has “Access this computer from the network” rights on the local system. You can add it via Group Policy if necessary via the Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Access this computer from the network policy setting.

For more details, see VMware’s KB on the topic.

-Rick

Outlook Prompts for Autodiscover Credentials Mid-Session

This one is for a very specific and probably uncommon scenario, but it drove me (and everyone else) up a wall and took a ton of man, and Microsoft Support, hours to finally resolve, so hopefully this will save some headaches.

Some background; We were in the middle of a migration to a new Exchange Server that sat on a separate domain from our Windows desktop clients with no trust relationship established (long story). We were successfully able to update our users’ Outlook clients to point to the new server address, and when launched Outlook prompted for authentication credentials to connect. This worked well enough, aside from our users being forced to use different credentials to log into their computers and to access their email, and everything functioned pretty much normally once authenticated. To help streamline the process of opening Outlook by avoiding the login prompt on launch, many of our users took to storing their secondary credentials locally using Windows Credentials Manager.

However, we started getting reports from users who used these cached credentials that they were being frequently prompted while Outlook was open, mid-session, to authenticate with an Autodiscover.domain server address. The Autodiscover address was displayed as being on the same domain as the workstation despite no Exchange Server residing there, and the prompt could be cleared by either hitting cancel or using credentials for the new Exchange Server’s domain. Regardless, the prompt would continue to reappear every few hours.

We were banging our heads against the wall for several days, trying everything we could think of and any suggestion we could find on the web, including wild-carding both domain addresses in Credentials Manager (for example *.contoso.com, to borrow from Microsoft), but absolutely nothing worked. Finally we stumbled upon the somewhat counter-intuitive solution with Microsoft Support’s help.

To prevent the Autodiscover prompt from appearing, we effectively had to bypass the use of cached credentials by forcing the prompt for logon credentials on launch via a setting in the user’s Outlook profile. Instructions for doing this are below.
 
In Outlook 2007:
1. Click Tools -> Account Settings
2. On the E-mail tab, highlight the Microsoft Exchange account and click on the Change button
3. Click the More Settings button
4. Click the Security tab
5. Check the box next to Always prompt for logon credentials
6. Click Apply and then OK
7. Click Next and then Finish

In Outlook 2010:
1. Click File -> Info -> Account Settings
2. On the E-mail tab, highlight the Microsoft Exchange account and click on the Change button
3. Click the More Settings button
4. Click the Security tab
5. Check the box next to Always prompt for logon credentials
6. Click Apply and then OK.
7. Click Next and then Finish.

So, again, this had the effect of forcing the prompt for credentials to connect to the Exchange Server when Outlook is first run, even if credentials are cached for that address. Still an inconvenience but, since most of our users would open Outlook and leave it running in the background, many found a single prompt at first was preferable to periodic prompts throughout the day.

-Rick

WSUS Role Installation Fails on Windows Server 2012 R2

I was attempting to add the WSUS role on a Windows Server 2012 R2 system earlier this week and I ran into this error during the installation.

“The request to add or remove features on the specified server failed. the operation cannot be completed because the server that you specified requires a restart.”

After several subsequent reboots and attempts to add the role I continued receiving this same error, so I started doing some research. I got several hits and this appears to be a fairly common issue with Server 2012, specifically when choosing to use the Windows Internal Database (WID).

The issue is that WID relies on the NT SERVICE\MSSQL$MICROSOFT##WID account to start the service, and this account must have Log on as a service rights on the system.

Generally I don’t think this would be an issue, and if it is you should be able to simply use the local Group Policy editor (gpedit.msc) or a domain GPO to grant this account Log on as a service rights by using the following policy setting:

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Log on as a service

Open the Log on as a service setting, check the box to Define these policy settings, and then add NT SERVICE\MSSQL$MICROSOFT##WID

However, to maintain security compliance as we move to Server 2012 R2, a domain Group Policy was recently created using Microsoft’s Security Compliance Manager (I may write a separate post on SCM later) and applied. As part of the Windows Server 2012 Security Baseline, Microsoft adds NT SERVICE\ALL SERVICES to the Deny log on as a service security policy. So because ALL SERVICES is being denied, even after adding MSSQL$MICROSOFT##WID to the Allow log on as a service policy locally, the WSUS role still failed to install for me.

To finally get the WSUS role installation to complete, I had to modify this new domain Group Policy and remove the ALL SERVICES account from the Deny log on as a service policy first, then add NT SERVICE\MSSQL$MICROSOFT##WID to the Log on as a service policy setting locally on the server.

For some more details and a few screenshots of the initial troubleshooting and resolution to this issue, check out one of the blog posts that I came across during my research. WSUS Role failed on Windows server 2012 with error…

You may notice that the blog I linked as well as many others I came across recommend just adding NT SERVICE\ALL SERVICES to the Log on as a service setting. Since Microsoft’s baseline security settings for Server 212 specifically DENIES log on as a service access to ALL SERVICES, I opted to only add the account explicitly required by WID to avoid opening up any more security vulnerabilities than I had to.

I’ll need to go back and take another look at our Server 2012 security policy to see if there’s another way around this while still denying log on as a service access to unneeded service accounts. I guess the easiest (and maybe best) thing to do would be to avoid using WID all-together and instead use a SQL Server instance.

That also leads me to another interesting topic that I’ll probably write another post about down the road. I’m installing WSUS with WID for now for the sake of time, but I may migrate it over to a SQL Server once I can. For a preview of that job, check out Migrate Windows Internal Database to SQL Server.

Links in this post:

 

-Rick

Recreate the Local Group Policy Cache in Windows

Happy Monday!

This is something I ran into a while back and has come in handy on several occasions.

For those who may be unaware (as I was before stumbling upon this trick), Windows maintains a local cache of all the group policy settings that are applied to that particular system. This cache can occasionally become corrupt or de-synchronized with the domain controller, which can cause a variety of issues including failure to apply new group policy settings or changes to existing policies.  When this occurs, the quickest and easiest way that I’ve found to correct it is to clear and recreate this local cache.

To clear the local GPO cache, make sure you can view hidden files and folders and perform the following:

  1. Browse to C:\ProgramData\Microsoft\Group Policy\History (Windows 7 / Server 2008)
  2. Delete all of the contents under the History folder
  3. Open the command prompt and run GPUpdate /force
  4. Reboot the system

I initially came across this while troubleshooting a Windows 7 client that was flat out refusing to apply new Group Policy settings. After ruling out the new GPO itself by checking it for content errors, verifying that it was linked up to the proper OU in Active Directory,  the link order was correct, and security filtering properly configured, I turned to the client for additional troubleshooting. A GPResult confirmed that the new GPO wasn’t being read and, other than some generic group policy errors, the Event Logs proved inconclusive. So I eventually turned to the web and come across this article on the Windows Server TechNet forums where someone mentioned attempting to clear the local GPO cache, which worked like a charm.

Rebuild the Windows WMI Repository

For my first technical post, I’ll try to keep things relatively quick and simple.

Rebuilding the WMI Repository is something that’s pretty well documented in various outlets, including Technet, but it’s been so useful to myself and many of my colleagues that I’d like to share it here.

As mentioned in the linked article: “The WMI Repository “%windir%System32\Wbem\Repository” is the database that stores meta-information and definitions for WMI classes; in some cases the repository also stores static class data as well. If the Repository becomes corrupted, then the WMI service will not be able to function correctly.”

In my personal experience, rebuilding the WMI repository has come in most handy when repairing the SCCM 2007 client after it stops working properly on Windows 7 systems, so if you’re an SCCM Admin and can’t figure out why some of your clients aren’t receiving advertisements, consider giving this a try. I imagine this could also be useful when troubleshooting issues for almost any application or service that relies on WMI. However, please keep in mind that this is generally recommended AS A LAST RESORT because, again from said article, “Deleting and rebuilding the repository can cause damage to the system or to installed applications”, so proceed with caution.

To repair the local WMI repository in Windows:

  1. Open an elevated command prompt
  2. Type net stop winmgmt and hit Enter. This stops the WMI service. (Side note: I’ve had instances where the WMI service is unable to stop after running this command. If this is the case, open the Services applet and set the Windows Management Instrumentation service Startup Type to Disabled and reboot the computer before proceeding)
  3. Use Windows Explorer to navigate to: %systemroot\system32\wbem
  4. Delete or rename the Repository folder (I usually like to add .old to the end of the folder name, so Repository.old)
  5. Return to the elevated command prompt and enter: net start winmgmt (Set the Startup Type back to Automatic for the WMI service first if you disabled it previously)
  6. Enter: cd /d %windir%\system32\wbem
  7. Re-register the dlls by entering: for %i in (*.dll) do RegSvr32 -s %i
  8. Reboot the system

These steps might differ a little bit from what you might find elsewhere, but this process has always worked well for me and my colleagues.

The Technet article that I referenced previously also lists some additional commands that you can run to verify and repair the WMI repository automatically on Windows Vista and above, but I haven’t tested them myself so I can’t vouch for their effectiveness. Those commands are:

  • winmgmt /verifyrepository  checks the WMI repository for consistency
  • Winmgmt /resetrepository – resets the WMI repository back to its initial state after the OS was first installed

So there you have it. This post didn’t turn out nearly as short and concise as I hoped, but this trick is something that I always keep well documented and close at hand, so I hope someone else is able to find it useful.

-Rick