Bloggy McBlogface

Recently I restored the OperationsManager database for an Operations Manager 2012 SP1 environment. For background, the environment consists of two management servers and a database server, all running Windows Server 2012 and the database server also running SQL 2012.

The backup and restore was performed through the SQL Management Studio using disk-based backups to a .bak file. The restore was performed to a different location using mount points which split the user database, system database, temp database and logs onto different volumes.

Before the backup was performed, all Operations Manager related services were stopped on the management servers, and after the database was restored all services were started successfully. When trying to access the console, however, I received the following message: –

Execution of user code in the .NET Framework is disabled. Enable “clr enabled” …

Additionally, the following events were logged on the management servers: –

Event ID: 26319, Source: OpsMgr SDK Service

An exception was thrown while processing GetFoldersByCriteria for session ID uuid:bf0e0661-c7d6-4af4-9d0a-836bd398b5d0;id=5.

Exception message: The creator of this fault did not specify a Reason.

Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnknownDatabaseException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to Execution of user code in the .NET Framework is disabled. Enable “clr enabled” configuration option.

Could not use view or function ‘dbo.fn_FoldersView’ because of binding errors.).

And…

Event ID: 33333, Source: DataAccessLayer

Data Access Layer rejected retry on SqlError:

Request: FoldersByCriteria — (LanguageCode1=ENU), (LanguageCode2=), (Id0=2e75d26b-7431-9af4-ee9d-456536676ba4)

Class: 16

Number: 4413

Message: Could not use view or function ‘dbo.fn_FoldersView’ because of binding errors.

Following the error message’s advice to enable “clr enabled”, I executed the following query on our Operations Manager database server: –

sp_configure ‘Show advanced options’, 1;

GO

RECONFIGURE;

GO

sp_configure ‘Clr enabled’, 1;

GO

RECONFIGURE;

GO

You should receive the following query output: –

Configuration option ‘show advanced options’ changed from 0 to 1. Run the RECONFIGURE statement to install.

Configuration option ‘clr enabled’ changed from 0 to 1. Run the RECONFIGURE statement to install.

Now you should be able to open your Operations Manager console!

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.