Category: Windows

I’m going through a process at the moment of upgrading my Server 2008 R2 lab environment to Server 2012. This week I decided I would do a fresh install of Server 2012 on one of my Hyper-V hosts. I backed up all of my VM’s to an eSATA drive, and then performed a clean install of Server 2012.

When the operating system was installed, I added the Hyper-V role and re-created one of my machines in System Center Virtual Machine Manager, then attached the original VHD’s.

Unfortunately, when I tried to power up the first “imported” machine, the Hyper-V host completely froze. No caps or num lock response. I had to hard reset it to bring it back online, after which my first step was to try to start the VM again. Same deal.

I then created a fresh machine, with no OS installed and tried to boot that. Yet again, the Hyper-V host locked up. Even a blank VM with no drives at all caused the Hyper-V host to freeze or lock up as soon as it was powered up.

Given the nature of the problem (no BSOD), there was no crash dump to analyse, and no Windows Event Logs to look through.

At this stage, I was almost certain I had a hardware issue, but this was working fine on Server 2008 R2. Although this server is a white box server build, I have previously found that the Dell diagnostics software that came with Dell equipment that I have previously bought, tends to work pretty well in diagnosing generic hardware issues. I created a bootable USB stick using the Dell diagnostic software, and then ran through all the tests. Everything passed. A burn-in test with BurnInTest from Passmark also succeeded with everything set to maximum load.

I then started doing some research in to the particular hardware combination I had, with interest to Hyper-V and Server 2012. The system is a Gigabyte GA-970A-D3 Motherboard, AMD Phenom II X2 555 and 32GB DDR3 G.Skill RAM.

My initial research seemed to indicate that USB 3.0 on Gigabyte motherboards has been causing issues for people when running Windows 8 and Server 2012. I checked my settings, and it was enabled. I disabled it, again certain this would resolve the issue.

No dice!

The solution is the end for me, was actually pretty simple (as it normally is when you spend hours troubleshooting an issue like this). I just needed to disable C1E support in the BIOS. For good measure, I also performed a BIOS update and disable the Cool & Quiet power options in the BIOS as well.

My VM’s now start perfectly, and I can continue migrating the rest of them on to my new Server 2012 environment.

Windows Server 2012 has been available for a few months now, and many organisations have begun to roll out the new technology.

A colleague of mine and myself have had some negative experiences with NetApp filters. It is important to note that there are some significant changes relating to authentication and file access with third party network storage devices. The organisation where I work uses NetApp filers, and the two biggest issues we have encountered are: –

• Resource SID Compression
• SMB Secure Negotiate

These two items both result in the inability to access resources on our NetApp filers, until registry keys are applied to the operating system to disable this additional functionality.

In order to disable Resource SID Compression, you must apply the following registry key to all Windows Server 2012 domain controllers: –

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kdc\Parameters\DisableResourceGroupsFields (DWORD) = 1

In order to disable SMB Secure Negotiate, you must apply the following registry key to all Windows Server 2012 and Windows 8 clients: –

HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecureNegotiate (DWORD) = 0

More information is available in the following articles: –

• http://support.microsoft.com/kb/2774190
• http://support.microsoft.com/kb/2686098

Issue

When attempting to remove a namespace server from a domain based DFS namespace, you receive the following error: –

\\fqdn.domain\namespace: The namespace server \\SERVER\NAMESPACE cannot be forcibly removed. The system cannot find the file specified

Cause

This issue is caused due to an inconsistency with the namespace server list maintained in Active Directory.

Resolution

1. Using adsiedit.msc, locate the DFS namespace object under the System\Dfs-Configuration container in the domain partition.
2. Open the properties of the DFS namespace object and locate the remoteServerName attribute
3. Edit the remoteServerName attribute and add the path to the namespace server and namespace folder you are trying to remove, for example \\SERVER\FOLDER
4. Save the object and allow for Active Directory replication time to the domain controllers in the site where your DFS management console is running from
5. Attempt to remove the DFS namespace server again

 If you’ve ever tried to set permissions on a GPO using Powershell, and you’ve encountered an error that the user is “not a valid user” in your domain, you’ve probably also noticed (at least at the current time of writing) that very little information exists about this issue.

I encountered this problem after trying to execute the following Powershell command to make a simple permission change on a GPO: –

Set-GPPermissions -name “My Policy” -PermissionLevel “GpoEditDeleteModifySecurity” -TargetName “MyUser” -TargetType “User”

Running the above command was given me the result below: –

Set-GPPermissions : The operation cannot be completed because “<USER>” is not a valid user in the <FQDN> domain.
Make sure that the TargetName and TargetType parameters specify a valid user for the domain. Then, run the command again.
Parameter name: TargetName
At line:1 char:18
+ Set-GPPermissions <<<<
    + CategoryInfo          : ObjectNotFound: (Microsoft.Group…missionsCommand:SetGPPermissionsCommand) [Set-GPPermissions], ArgumentException
    + FullyQualifiedErrorId : TargetNotFound,Microsoft.GroupPolicy.Commands.SetGPPermissionsCommand

Reading the examples of the Set-GPPermissions command, I just couldn’t see where I was going wrong, so I was sure it had to be a bug. Unfortunately, there’s hardly any information about the problem… Except a hotfix from Microsoft that doesn’t mention the specific issue, however does resolve it!

The hotfix is KB978838, and mentions a different error message and only applied to “non-English” versions of the Windows operating system. I was not having the issue described, and am running an English version of Windows Server 2008 R2, however I think my scenario came close enough to warrant testing the hotfix, for the following reasons: –

• I was having issues with what would likely be the same function in the Powershell cmdlet
• I am in Australia, and have it set as my locale

So if you are wondering if the hotfix will work for you, the chances are “yes” based on my experience.

It seems that there are an increasing number of locale related bugs in Microsoft products since the release of Vista onwards. If anyone from Microsoft stumbles across this, could I suggest passing on a message that the USA isn’t the only English speaking country in the world, and aren’t the only users of your products!

EDIT: I can confirm that Windows 7/Windows Server 2008 R2 Service Pack 1 also corrects this issue.

Today I decided to change the way that my folder redirection policy was applied to my workstations.

Previously, it was the stock-standard folder redirection policy that was targeted to the OU containing my user accounts, however I wanted to have the ability to exclude some machines from this (I build a lot of virtual machines and don’t want folder redirection applying to these).

In order to achieve this, you’ll need to use loopback policy processing so you can apply the user configuration based on computer rather than user.

The two main ways of achieving this are by employing multiple OU’s (my least favourite) or by using security groups. I prefer security groups, because it means you can have one group that contains all of the machines to which folder redirection should be applied, without needing to create a seperate OU in every location/office/branch you may have.

The OU method

1. Generally, you’d want to create a sub-OU under the OU that contains your computer accounts. You might want to call this something like “Folder Redirection Enabled Computers” or whatever makes you happy.

2. Create a policy, and configure your folder redirection settings to your liking, and then under Computer\Administrative Templates\System\Group Policy, enable the setting “User Group Policy loopback processing mode” and set it to “Merge”

3. Now add the machines that you want to apply the folder redirection to, to the OU you created with the policy linked

The security group filtering method

1. Create a security group called something like “Folder Redirection Enabled Computers” and add all of your required machines to this group

2. Create a new policy, and remove Authenticated Users under the Security Filtering tab, then add Domain Users and the group you created in the above step

3. Edit the policy configuring your folder redirection settings to your liking, and then under Computer\Administrative Templates\System\Group Policy, enable the setting “User Group Policy loopback processing mode” and set it to “Merge”

4. Link the policy to the OU that contains your computer accounts

As I mentioned, I prefer the use of security group filtering for this purpose, because I find it more scalable – You just link the policy to the OU(s) that contain your computer accounts, and add the computers to actually apply folder redirection settings to your custom group.

Note that you do need to ensure that the user account can read the policy as well, even though with loopback policy processing, it will be applied based on the computer account. This is because the policy passes through the user security filter to, so if you don’t have Domain Users added to the security filter (or at least a group that will contain the user(s) logging on to your desired machines) then the policy won’t apply.

In Windows 7, there is a fair level of detail in both the Application event log, as well as the dedicated Folder Redirection event log, so I recommend watching these logs remotely during a logon to make sure everything is behaving the way you expect it to.

This is just a quick post for an issue I encountered quite a while ago (this article has been in my drafts since September last year, so I hope I am recalling the details correctly).

Basically, I had a stock-standard advertisement targeted to my machine for testing. The advertisement program pointed to an installer, which when it ran, throws up an “Open File – Security Warning” message box. Obviously you’d typically see this for non-trusted sources, such as network locations and downloaded files, however this was sitting on a trusted UNC path where all programs are targeted, and this issue had never occurred before.

After some brief digging, I found that the message would only appear if the FQDN was used to call the program, but the NetBIOS name was fine. Unfortunately, SCCM uses the FQDN for it’s advertisements, and therefore I had to work out what was going on.

In short, after a bit of Process Monitor use, it appeared that the issue was actually with the .exe making a call to another setup program, which was the actually setup program to install the application. When I found this, I didn’t bother digging any further to find out exactly what was going on, because updating the program to point to the setup program that the original .exe was calling fixed the problem.

So if you have this issue, maybe see if the .exe you’re targeting is just a stub for another setup program, and just target that directly.

I’ve noticed there’s a bunch of conflicting information about how robocopy works when it replicates files. This causes confusion to administrators who can’t work out why a bunch of files in a folder that have had inheritance removed, no longer receive ACL updates.

With the standard parameters, robocopy only checks the file contents when comparing if files have changed, which doesn’t include ACLs. This isn’t a problem on directories – The ACLs will be copied across as expected.

In order to have robocopy copy the ACLs for individual files across to the destination directory, you can run “robocopy /e /copy:s /is”.

This will copy security (/copy:s = copy security) for all files including in subdirectories (/e = everything) even if the file contents haven’t changed (/is = is same). It’s important to note that if you use /copyall or any other parameter that includes file contents, then the entire file contents will replicate (when using the /is parameter), so you’ll want to make sure that you don’t do this if you have a very large amount of data that you’re transferring over a WAN link, for example, and all that needs changing are ACLs.

If you have issues with SCCM deployed software updates failing to download and install, try checking the UpdatesHandler.log file (I recommend using trace32.exe with the SCCM Toolkit).

The particular problem I experienced, resulted in the following lines being written to the UpdatesHandler log: –

Unable to get locations, no need to continue with download

CBundledUpdate — Failed to download update (1a5ada44-c5cd-11de-a7e1-001372775900). Error = 0x80040669

CDeploymentJob — Failed to download update (1a5ada43-c5cd-11de-a7e1-001372775900). Error = 0x80040669

Note that these are seperate log entries, and are not written consequetively.

In this case, expand the Software Updates node in the appropriate Deployment Package in which the update is stored, locate the failed update and click on the Content Information tab (there will most likely be multiple updates with the name Article ID for different operating systems).

Individually selecting each of the updates that match the Article ID, ensure that all of the relevant files with unique Content IDs are marked as downloaded (i.e. in the Downloaded column it reads Yes).

There may be Content IDs for different languages, and these can be ignored.

If there are records with unique Content IDs that are not downloaded, the update should be re-downloaded and re-deployed using the usual method.

A code signing certificate is a security measure designed to assist in the prevention of malicious code execution. The intention is that code must be “signed” with a certificate that is trusted by the machine on which the code is executed. The trust is verified by contacting the certification authority for the certificate, which could be either a local (on the machine itself, such as a self-signed certificate), internal (on the domain, such as an enterprise certification authority) or external certification authority (third party, such as Verisign or Thawte).

For an Active Directory domain with an enterprise root certification authority, the enterprise root certification authority infrastructure is trusted by all machines that are a member of the Active Directory domain, and therefore any certificates issued by this certification authority are automatically trusted.

In the case of code signing, it may be necessary also for the issued certificate to be in the “Trusted Publishers” store of the local machine in order to avoid any prompts upon executing code, even if the certificate was issued by a trusted certification authority. Therefore, it is required to ensure that certificates are added to this store where user interaction is unavailable, such as running automated processes that call signed code.

A certificate can be assigned to a user or a computer, which will then be the “publisher” of the code in question. Generally, this should be the user, and the user will then become the trusted publisher. As an example, members of the development team in your organisation will probably each have their own code signing certificate, which would all be added to the “Trusted Publishers” store on the domain machines. Alternatively, a special domain account might exist specifically for signing code, although one of the advantages of code signing is to be able to determine the person who signed it.

The processes below details the steps required to generate a code signing certificate, export the certificate and private key, and import the certificate to a local machine or to a group of machines through the use of group policy.

Creating the Code Signing Certificate Template

1. Open the “Certification Authority” console on the enterprise root certification authority
2. Click on “Certificate Templates” and check if a template called “Code Signing” exists (if it already exists, there are no further steps required for this section)
3. If the “Code Signing” template does not exist, right click on the “Certificate Templates” node and select “New” -> “Certificate Template to Issue”
4. Select “Code Signing” and click OK

Generating the Code Signing Certificate

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “My user account” when prompted)
3. Expand “Personal”, right click on “Certificates” and select “All Tasks” -> “Request New Certificate”
4. Select “Active Directory Enrollment Policy”
5. Tick “Code Signing” and then click on the “Details” button to the right hand side of the “Code Signing” option
6. Click on “Properties”
7. Click on the “Private Key” tab, and then expand the “Key Options” section
8. Tick “Make private key exportable” and “Strong private key protection”
9. Click OK and then click the “Enroll” button (a message may appear stating that an application is creating a protected item – click OK to acknowledge this message)

Exporting the Certificate for Publishing

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “My user account” when prompted)
3. Expand “Personal”, right click on the appropriate code signing certificate and select “All Tasks” -> “Export…”
4. Choose the option “Yes, export the private key” when prompted
5. Accept the default options on the “Export File Format” screen
6. Enter a password for the private key, which will need to be entered when importing the certificate
7. Save the certificate to an appropriate location

Importing the Certificate for Trusting

Local Machines

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “Computer account” and select the local machine when prompted)
3. Right click “Trusted Publishers” and select “All Tasks” -> “Import…”
4. Follow the wizard to import the exported certificate, and enter in the accompanying password that was used when the certificate was exported
5. If the certificate is no longer required to be imported by other machines, it is highly recommended that the exported file is deleted  

Group Policy

1. Open the appropriate group policy for editing
2. Expand “Computer Management” -> “Policies” -> “Windows Settings” -> “Security Settings” -> “Public Key Policies”
3. Right click on “Trusted Publishers” and select “Import…”
4. Follow the wizard to import the exported certificate, and enter in the accompanying password that was used when the certificate was exported
5. If the certificate is no longer required to be imported by other machines, it is highly recommended that the exported file is deleted