SCOM- Could Not Determine the FSMO Role Holder

Update June 2012: I've just recently came across a cool workaround blog post on this issue by Stefan Roth that requires a change to each Domain Controller you are managing that creates a symbolic link that would allow this task to be run each time. Check out his post below:

http://blog.scomfaq.ch/2011/12/04/support-tools-task-in-active-directory-management-pack-fails/

When you install the Active Directory (AD) Monitoring Management Pack into your SCOM/OpsMgr environment, from time to time you will come across the error 'Could Not Determine the FSMO Role Holder', followed quickly by the errror 'AD Client Side - Script Based Test Failed to Complete'.

This is an annoying little error that has a relatively easy fix.

Cameron Fuller and the guys behind the 'System Center Operations Manager Unleashed' series have a good post on their blog containing a lot of resolutions to these type of errors generated from the Active Directory Management Pack - see the link below:

http://opsmgrunleashed.wordpress.com/2009/09/29/opsmgr-r2-by-example-the-active-directory-management-pack/

Following the information from the blog post above, we would select the 'Netdom Query FSMO' task on the right hand side of the screen when you have the 'Could Not Determine the FSMO Role Holder' alert highlighted

 This will open a window like the one below. Have a look at the location of the 'Support Tools Install Dir' Value. It is pointing to the '%ProgramFiles%\Support Tools' location

 When we run the task without changing anything, it will come back and fail with an error like below

The reason it fails is because the NetDom utility doesn't exist on the Domain Controller that is raising the alert in the %ProgramFiles%\Support Tools location. It is existent in the '%windir%\system32' location instead. If we choose to re-run the task but this time select the 'Override' button and modify the 'Support Tools Install Dir' value to point to the correct location of the NetDom utility, it will complete successfully as the screens below show.

Most of the time, simply by carrying out the above procedure, this error will go away as the FSMO role holder has been enumerated but in a few instances, we need to make one or two more small changes.

If the alert comes back after the above process, all you need to do is to locate the 'NetDom' utility from within the %windir%\System32 directory, create a new folder under the 'Program Files' folder on the Domain Controller giving the error called 'Support Tools' and then copy the 'NetDom' utility to here like the screenshot below

Now you can run the task again successfully without having to make any overrides or custom changes to your SCOM environment.

Hopefully after these changes, the rule should be able to run the NetDom utility and determine the FSMO role holder of each domain controller.

Using The Active Directory Recycle Bin to Recover a Cluster Name Object (CNO) for Windows Server 2008 R2 Failover Clusters

This is another excellent post that I came across this weekend while catching up on whats been happening in the blog world!

Last year I had to recover a customers Hyper V cluster as an admin onsite in the customers premises decided to do a little 'Active Directory Tidy Up' and deleted the Cluster Name Object (CNO) for the Windows 2008 R2 Failover Cluster!!

I found this Technet article at the time and after reading through it I wanted to give it a go but unfortunatley the customer site didn't have a Windows Server 2008 R2 domain controller and I ended up just rebuilding the cluster (it was only a 2 node Hyper V with all the VM's backed up with DPM).

I remember thinking how useful and time-saving the Active Directory Recycle Bin would be if I was faced with a similar issue again but then completly forgot all about it until I read these blog posts from Chuck Timon and  John Marlin (Senior Support Escalation Engineers with Microsoft).

This is going to become a staple part of any new Windows Server 2008 R2 Domain Controller installations that I do because the amount of time that can be saved with this process is unbelievable when compared any of the alternatives.

I highly recommend anyone reading this to add it as a standard part of their Windows 2008 R2 installations in future and even would go so far as to recommend adding it in now to any Windows 2008 R2 Domain Controllers on your customer sites.

Here are the links to both blog postings, the original one being authored by Chuck Timon in 2009 when nobody really had Windows Server 2008 R2 in mainstream use and the second and more recent one authored by John Marlin, who goes deep into the Active Directory Recycle Bin utility and how to recover from it.

Chuck Timon
http://blogs.technet.com/b/askcore/archive/2009/04/27/recovering-a-deleted-cluster-name-object-cno-in-a-windows-server-2008-failover-cluster.aspx

John Marlin
http://blogs.technet.com/b/askcore/archive/2011/05/18/recovering-a-deleted-cluster-name-object-cno-in-a-windows-server-2008-failover-cluster-part-2.aspx

Now, no more excuses for having to spend two days onsite rebuilding a cluster due to the CNO being deleted by some 'smart' thinking sys admin!

Enjoy!

KMS Minimum Clients (Activation Thresholds)

I came across this issue during the week when I was reading into KMS licensing in a bit of detail and thought it might be something worth sharing as I hadn't realised there were a minimum number of activations required for KMS to operate. Here's the official text from Microsoft's website on the subject:


KMS requires a minimum number of either physical or virtual computers in a network environment. These minimums, called activation thresholds, are set so that they are easily met by enterprise customers.

For computers running:

• Windows Server 2008 and Windows Server 2008 R2 you must have at least five (5) computers to activate.

• Windows Vista or Windows 7 you must have at least twenty-five (25) computers to activate.

• For Office 2010, Project 2010 and Visio 2010 you must have at least five (5) computers to activate. If you have deployed Microsoft Office 2010 products, including Project 2010 and Visio 2010, you must have at least five (5) computers running Office 2010, Project 2010 or Visio 2010.

Active Directory and Exchange Topology Diagrammer

I came across this tool a couple of years ago, demo'd it, thought it looked great but forgot about it and never used it in a live environment.

Last week I started a project which required a full audit of a fairly large Exchange 2007 network that spread throughout 13 sites worldwide. As part of the audit, I set about creating a Visio diagram of the Exchange Organization but soon ran into trouble trying to map out all of the site links and detailed information.

That's when I remembered Microsoft's Active Directory Topology Diagrammer. This is a really handy tool when you want to create Visio diagrams of your networks and it covers Active Directory Site Structure, OU Structure and brilliantly the Exchange Organization structure too!

Download the tool from here and try it out, you will need Visio installed and with the latest Exchange stencils though for the tool to draw the diagrams properly:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=cb42fc06-50c7-47ed-a65c-862661742764&displaylang=en

Bulk Create Active Directory User Accounts and Exchange Mailboxes

Although this process is fairly well known at this point, I am continually asked for this PowerShell script to assist with the bulk creation of new Active Directory user accounts with passwords and then the bulk creation of Exchange Mailboxes for these new accounts. It will also allow you to create or specify an OU to place them into.

This script was created by Exchange MVP Andy Grogan.

Here's the link to the downloadable Powershell Script and sample CSV file that creates the user accounts within Active Directory:

http://www.telnetport25.com/component/content/article/15-powershell/321-quick-post-script-to-create-lab-users-powershell-version.html

Once you have modified the CSV file to suit your user structure and run the Powershell script, you should now have all of the users created within AD and all assigned passwords of your choice too.

The next step is to create new Exchange mailboxes for those users using the following process:

 You open the Exchange Management Shell and begin with Get-User.


If we imagine we have an OU we wish to grab all the users from we could just type Get-User –OrganizationalUnit <OU Name>. However, this will return to us all the users in that OU, whereas perhaps some are already mailbox enabled. To narrow down our grab we can use a request for RecipientType which we could say is equal to User (as opposed to UserMailbox, which would mean they already have a mailbox).

So, for example, if we want to locate all users in the Accounts OU that do not have mailboxes already for their accounts we could type:

Get-User –OrganizationalUnit Accounts | Where-Object [$_.RecipientType –eq "User"}

That command would get us part of the way there.

Now if we wanted to mailbox enable those users we would append to the end:

Enable-Mailbox –Database "<Name of Database>"

So, let’s say in our setup here we have the Accounts users in the Accounts OU and we want them all given mailboxes in a database called EX2010Database.

We would type the full command:
Get-User –OrganizationalUnit Accounts | Where-Object [$_.RecipientType –eq "User"} | Enable-Mailbox –Database "EX2010Database"

Now just sit back and let the script do all the hard work!