The following script does just that:

# Read in pst file locations and users
$strPSTFiles = Get-Content -Path "c:\pstdetails.csv"
foreach($strPSTFile in $strPSTFiles)
{
$strMachine = $strPSTFile.Split(',')[0]
$strPath = $strPSTFile.Split(',')[1]
$strOwner = $strPSTFile.Split(',')[2]

# Get network path for pst file
$source = "\\" + $strMachine + "\" + $strPath.Replace(':','$')

# import pst to mail box.
Import-Mailbox -PSTFolderPath $source -Identity $strOwner
New-MailboxImportRequest -FilePath $source -Mailbox $strOwner
}

The yellow highlighted text shows the Exchange 2010 RTM cmdlet, the red the Exchange 2010 SP1. Delete the unneeded version as appropriate.

The Exchange 2010 SP1 version of the script will execute in far less time, due to the asynchronous nature of the ImportRequest cmdlet. These requests are processed in the background and can be monitored with the Get-MailboxImportRequest cmdlet to observe their status.

There are quite a few potential pitfalls here:

1. The user’s machine must be on.
2. File sharing must be on, to allow for the file to be transferred.
3. Outlook must not be running on the remote user’s machine. If Outlook is running and has the PST file attached, the file will be locked and unable to be imported.
4. The PowerShell cmdlet used by Exchange to import PST files does not support passwords.

There are various things you could to augment this script.Some suggestions include:

•  Have WMI shut down Outlook on a remote user’s machine before attempting import http://www.computerperformance.co.uk/vbscript/wmi_process.htm
• It could be useful to generate a further file detailing a list of all the PSTs which failed to import, with the reason. These files could have been password protected, or the machine hosting them may have been shut down, or become disconnected since they were identified.

I hope you have found this series of articles on manually importing PST files into Exchange 2010 useful. Although, like me, I’m sure you feel that this is a bit of a mammoth task, particularly for the Powershell novice!

To start this, we  can query Active Directory for a list of all the machines attached to your domain. We can then use Windows Management Instrumentation (WMI) to search each of these machines for PST files. The file paths for these PSTs should hopefully give a clue as to which user they belong to, as they will be created in a directory path containing the username by default. We can also grab the file owner file attribute which should correlate with the file path.

This technique requires that all the machines in your network are switched on and accessible by WMI. A list of the machines which could not be queried can be provided as output

Notes about WMI:

By default WMI is blocked by the windows firewall in Windows 7 and 2008 R2. You’ll need to open up the ports on all your users’ machines. This can be done with the ‘netsh’ command, or through a change to group policy.

What are the implications of this? WMI is a powerful beast, and allows remote access to many aspects of a user’s machine. As such it could be considered a security vulnerability… It’s typically accessed though port 135. This not only permits access to WMI – but also any other DCOM components which may be installed on a machine, open for exploitation by Trojans and the like. Needless to say, the ports are blocked by default for a reason – so require careful consideration of the implications when opening. WMI will also not help you if the machines you wish to tinker with are subject to NAT (Network Address Translation). You’ll be unable to reach these machines. The following script generates a txt file (the filename defined on line 2) of all the computers on your domain to be searched. This can then be edited with notepad to remove those you don’t wish to search.

$strCategory = "computer"
$strOutput = "c:\computernames.txt"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.Filter = ("(objectCategory=$strCategory)")

$colProplist = "name"
foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}

$colResults = $objSearcher.FindAll()
[bool]$firstOutput = $true
foreach ($objResult in $colResults)
{
$objComputer = $objResult.Properties;
if($firstOutput)
{
Write-output $objComputer.name | Out-File -filepath $strOutput
$firstOutput = $false;
}
else
{
Write-output $objComputer.name | Out-File -filepath $strOutput `
-append
}
}

The next script will generate a CSV (Comma separated values) detailing the network paths of the PSTS you need.

$strComputers = Get-Content -Path "c:\computernames.txt"
[bool]$firstOutput = $true
foreach($strComputer in $strComputers)
{
$colFiles = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query "Select * from CIM_DataFile `
Where Extension = 'pst'"
foreach ($objFile in $colFiles)
{
if($objFile.FileName -ne $null)
{
$filepath = $objFile.Drive + $objFile.Path + $objFile.FileName + "." `
+ $objFile.Extension;
$query = "ASSOCIATORS OF {Win32_LogicalFileSecuritySetting='" `
+ $filepath `
+ "'} WHERE AssocClass=Win32_LogicalFileOwner ResultRole=Owner"
$colOwners = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query $query
$objOwner = $ colOwners[0]
$user = $objOwner.ReferencedDomainName + "\" + $objOwner.AccountName
$output = $strComputer + "," + $filepath + "," + $user
if($firstOutput)
{
Write-output $output | Out-File -filepath c:\pstdetails.csv
$firstOutput = $false
}
else
{
Write-output $output | Out-File -filepath c:\pstdetails.csv -append
}
}
}
}

This script will take as input a text file containing a list of machine names (conveniently the output of the first script), and will generate a csv file of all the pst files found on those machines, and the owners associated with them.

A PowerShell cmdlet in the EMS is used to perform the action. Use of this cmdlet requires that the current user has Import Export mailbox roles on their profile. Exchange 2010 RTM also requires that Outlook 2010 x64 is installed on the machine. This is no longer a requirement of Exchange 2010 SP1.

So, to import a single PST file into an Exchange 2010 mailbox:

• Install Outlook 2010 64-bit on the Exchange Server. By default, on a machine with no pre-existing Office installation, the 32-bit applications will install from the DVD’s autorun setup. Be sure to manually run the install from the x64 directory to install 64-bit Outlook. This step is not necessary for Exchange 2010 SP1, as this includes a MAPI provider.
• Enable import permissions for a security group your user belongs to (in this case ‘Mailbox Support’) with the command:New-ManagementRoleAssignment -Name "Import Export Mailbox Admins" `
-SecurityGroup "Mailbox Support" `
-Role "Mailbox Import Export"

• Import the PST file into the appropriate user’s mailbox with the following command:Import-Mailbox -PSTFolderPath pstfilepath -Identity exchangealias 

Exchange 2010 SP1 differs a little in that you don’t need to install Outlook 2010 x64, and rather than the synchronous ‘Import-Mailbox’ cmdlet, the asynchronous ‘New MailBoxImportRequest’ can be used.

This takes the form of:

New-MailboxImportRequest -FilePath pstfilepath -Mailbox mailbox

One of the advantages of this new cmdlet (other than being asynchronous), is that you can specify an additional –IsArchive parameter, which will import the PST into the user’s archive mailbox.

I did experience a few problems using these cmdlets during  my research for this guide. The Exchange 2010 RTM Import-Mailbox on one system refused to play nicely, throwing the following error:

Error:
Error was found for XXX because: Error occurred in the step: Approving object. An unknown error
has occurred., error code: -2147221219
+ CategoryInfo : InvalidOperation: (0:Int32) [Import-Mailbox], RecipientTaskException
+ FullyQualifiedErrorId : CFFD629B,Microsoft.Exchange.Management.RecipientTasks.ImportMailbox

Not a lot of help in itself – a little Googling and experimentation revealed four main causes for this error:

1. The appropriate role permissions had not been added to the user’s security profile.
2. The version of MAPI being used had somehow got confused. Running the ‘fixmapi’ command from the command prompt should fix this.
3. The PST file is password protected.
4. There is a bug in Exchange.

In my case I’d unfortunately hit the fourth case and the work around proved to be pretty horrific It may simply be worth waiting for a fix from Microsoft. To complete my task, I had to temporarily add a new domain controller to my network to host a new Exchange 2010 server. I then moved the mailboxes for which I had PSTs to import to this new server, performed the import, then moved the mailboxes back to their original Exchange Server, and removed the temporary server from the network. Upgrading the system to 2010 SP1 and using the ‘New-MailBoxImportRequest’ cmdlet  on the same system yielded the following error:

Couldn't connect to the target mailbox.
+ CategoryInfo : NotSpecified: (0:Int32) [New-MailboxImportRequest], RemoteTransientException
+ FullyQualifiedErrorId : 1B0DDEBA,Microsoft.Exchange.Management.RecipientTasks.NewMailboxImportRequest

Again, this appears to be a known issue, and apparently due to be fixed before the release of SP1.

In my next post I will go through finding PST files on your network the manual way.

Error:
Error was found for (username) because: Error occurred in the step: Approving object. An unknown error
has occurred., error code: -2147221219
+ CategoryInfo          : InvalidOperation: (0:Int32) [Import-Mailbox], RecipientTaskException
+ FullyQualifiedErrorId : CFFD629B,Microsoft.Exchange.Management.RecipientTasks.ImportMailbox

Here is how I worked round it.

After doing some digging,  I found the site http://www.korneel.nl/?p=28 that  identifies most of the problems you might hit importing a PST file.

The cause for the error in my case transpired to be an acknowledged (according to the blog post) bug in exchange, presumably with an upcoming hotfix. However, it seems to be a generic error for all ills, as other solutions on the web suggest using the ‘fixmapi’ command (though admittedly referring to exchange 2007…). http://social.technet.microsoft.com/Forums/en-US/exchangesvrmigration/thread/82424f36-2611-4188-808e-df9aad36a5b7 (And the most common suggestion being adding the import export role to the user account.)

Another potential pitfall is the requirement for the 64bit version of outlook 2010 to be installed. It’s worth noting that by default an installation of Office 2010 on a clean machine will install the 32bit version.

As an unrelated aside,  installing the SP1 beta on exchange also caused a few problems – it required the manual installation of several hot fixes – and more annoyingly one package (UCMA 2.0 Runtime 64bit)– which despite coming as an ‘msi’ installation package, and on running giving all the signs it had installed successfully – had actually only ‘installed’ the installation files, which then had to be run separately. I’m sure these niggles will be ironed out before SP1 is released, but it wasn’t the friendliest of upgrades.

This is what actually happens when an Exchange administrator initiates a New-MoveRequest, either from the Exchange Management Shell or the Exchange Management Console when moving a mailbox from EXMBX01 to EXMBX02 in the figure below.

The process of moving mailboxes is now performed by a service called Mailbox Replication Service or MRS. The MRS is running on the Client Access Servers.

1. The Administrator initiates a move request like New-MoveRequest –Identity J.Wesselius –TargetDatabase EXMBX02\MDB02. Now a special message is placed inside the System Mailbox of the current Active Directory site. This message tells that the Move Request is initiated and that its status is Queued;
2. The Mailbox Replication Service periodically scans this System Mailbox for these messages. The MRS will find the message and reads that the J.Wesselius mailbox is Queued;
3. The MRS will update the System Message to “In Progress” and will start moving the Mailbox data from EXMBX01 to EXMBX02. MRS will keep the old and the new mailbox in sync. The user is still connected via the CAS Server to EXMBX01, and arriving messages will be delivered via the Hub Transport Server to the Mailbox on EXMBX01;
4. At a certain point when almost all data is moved from the old to the new Mailbox the old Mailbox is locked. The last pieces of data are moved from the old to the new Mailbox. Also the Active Directory properties of the user are changed to point to the new Mailbox Database. At this point the status of the Move Request (i.e. the message is the System Mailbox) is changed from “In Progress” to “Completion in Progress”;
5. The new Mailbox is activated, the old Mailbox is soft deleted (which means that it is actually recoverable in SP1!) and the user needs to restart his client. When you move a Mailbox from an Exchange 2010 SP1 Mailbox Database to a Mailbox Database on another SP1 Mailbox Database the client does not need to be restarted.
6. Although the Mailbox is moved from server EXMBX01 to EXMBX2 the Move Request itself is not deleted. This has to be performed by the Administrator, either by using the Exchange Management Shell (Remove-MoveRequest) or by using the Exchange Management Console.

You can see the MRS run on the Client Access Server in the Windows Task Manager:

You can see the status of the move request by entering the following command in the Exchange Management Shell:

[PS] C:\download>Get-MoveRequest | ?{$_.status -eq “InProgress”}| Get-MoveRequestStatistics | ft Disp*,Per*,BytesTransferredPerMinute

DisplayName                 PercentComplete BytesTransferredPerMinute

———–                 ————— ————————-

Jaap Wesselius              66               134.2 MB (140,668,124 bytes)

Katie Price [HR Department] 66               119.9 MB (125,677,306 bytes)

[PS] C:\download>

The MRS is a throttled service, and it is fully configurable. There’s an MSExchangeMailboxReplication.exe.config file in the “C:\Program Files\Microsoft\Exchange Server\V14\Bin\” directory. You can use this config file to configure the throttling of the MRS by changing these entries:

• MaxActiveMovesPerSourceMDB
• MaxActiveMovesPerTargetMDB
• MaxActiveMovesPerSourceServer
• MaxActiveMovesPerTargetServer

How is this possible?  Could it be that single instance storage never really had real benefits?  Or maybe because it had been weakened in 2007 (so that only attachments within a storage group were single-instanced), we already paid the tax?

Well, the mystery has been solved:  in Exchange 2010, MS introduced compression.  In more detail,

“As a result of the new architecture and the other changes to the store and ESE, we had to deal with an unintended side effect.  While these changes greatly improved our IO efficiency, they made our space efficiency worse.  In fact, on average they increased the size of the Exchange database by about 20% over Exchange 2007. To overcome this bloating effect, we implemented a targeted compression mechanism (using either 7-bit or XPRESS, which is the Microsoft implementation of the LZ77 algorithm) that specifically compresses message headers and bodies that are either text or HTML-based (attachments are not compressed as typically they exist in their most compressed state already).  The result of this work is that we see database sizes on par with Exchange 2007.”

http://msexchangeteam.com/archive/2010/02/22/454051.aspx

So!  It seems that Microsoft has not been as off-hand with our storage as it seemed.  The message from Redmond has mostly been, ‘Ah, storage is cheap – and even cheaper for Exchange 2010 – so losing SIS isn’t a big deal.’

But, heart-warmingly, they were looking out for our storage needs all along.… which makes me wonder, why the shyness about the compression?  Yes, there will be a performance tax, but most Exchange servers are not performance-limited by the processor.

Is there some other disadvantage to compressing messages in the Exchange database?  I can’t think of one.

The article is based off of a 2010 Interop Las Vegas survey done by RiverBed Technology. Over 350 Interop attendees were surveyed. The results were interesting, but upon further inspection do not, I believe, suggest that IT departments are resisting the trend towards a decentralized technologist workforce and an increased usage of service providers.

In a nutshell, the survey shows that IT departments are centralizing their resources through private clouds and branch-office virtualization. The motivations are primarily to save money, reduce complexity (which really means “save money”) and increase security (which really means “save money”).

Upon a closer inspection, this survey suggests a trend towards centralized IT resources more than it does a centralized IT workforce. The survey seems to be poorly named. It may have been better to title it “Study Suggests IT Departments Seek Cost Savings Through Shared Resources and Reduced Complexity.”

In my opinion, centralized resources, particularly using an internal cloud, will make the individual technologists more flexible in their roles and be the enabling technology in redistributing them into individual business units. Also, the increased simplicity of pooled resources may allow for IT workers to be “let go” (a term which I hate) from a company’s IT workforce, or at least shifted to a different position within the business. Perhaps that different position will be one which is more closely aligned with a specific business unit as outlined in this previous SysAdmin-Talk post.

At it’s heart, this kind of consolidation is motivated by the same concern as most anything else is: money and the desire to make and retain more of it. Reduced complexity and increased security are built on top of the desire to reduce spending (whether in the form of management costs or fines). Increased flexibility would hopefully increase the potential for money to be made.

What does this portend, if anything? I think that when technology departments seek to consolidate their services en masse into internal clouds (a fancy term for what many of us have already started doing with the use of virtualization), it will cause reflection on which services they really want to keep in-house. Inevitably some will be handed off to outsourcers that specialize in the task. Hosted Exchange, Wikis and CRMs for example. Basically, if it doesn’t directly make money for the business or differentiate the business then it’s a prime candidate for outsourcing.

Much of what remains behind will be the specialized tasks and tools that are specific to individual departments. Those things will be absorbed into an internal cloud for easier management and the technologists that work on them will work directly in the departments that use the services. Ironically, those services that are kept and absorbed will likely be primed for migration to an external cloud provider if the standards that are often talked about by the likes of VMWare and even NIST come to fruition. What was once considered too risky to trust to the cloud may not be once certain concerns are addressed.

Business leaders may become more comfortable with external service providers the more those providers are shown to be successful and the more their security and SLAs are documented and guaranteed. What services remain in-house after the first round of “cloudification” would then be even more tempting to outsource when internal compute power begins to run thin and the cost of procuring hardware begins to make little sense and cloud providers can leverage the economy of scale in their favor. Of course, less services being provided in-house as well as the simplification of management that internal clouds can provide will mean the possibility, nay, the probability of less technologist jobs being necessary internally and more being made at external service providers.

The report mentioned four concerns that the surveyed individuals were mindful of as they centralized their resources. First was performance closely followed by security. Availability and migration issues distantly trailed in importance.

Those same concerns over an internal centralization of resources will ring true (and maybe even morseo) for service providers before they can be utilized in enough capacity to cause the predicted 75% reduction in internal IT workers. As those concerns are overcome, it will be all the easier and more desirable for an increasing amount of “undifferentiating” tasks to be outsourced.

After the internal consolidation is done or significantly progressed, that will free technology departments from their monolithic structures and allow for a healthy internal dispersal. SysAdmins will no longer have quite as much grunt work to tend to and the “grunty” tasks that remain will not be as disparate and thus easier to manage. I say that within 18 to 24 months we’ll see the first signs of the significant shift in technologist placement as well as in-demand skills. Technologists will begin the move towards closer relationships with business units or take up new positions at external service providers.

With quotes like this in the RiverBed study it seems that the change is upon us: “33 percent of respondents plan additional data center consolidation projects within the next 12 months.” (emphasis added)

This industry has certainly changed a lot in the few years I’ve been involved in it. Do you see the change in your own job? Are you readied for it?

This is much easier in Exchange 2007 than it was in Exchange 2003 as here we can use PowerShell. I would like to mention that in case of using Ex 2007, we don’t even have to create the users in advance, the server will take care of that for you. For the full 2007 PowerShell reference guide please see this page http://technet.microsoft.com/en-us/library/bb123703%28EXCHG.80%29.aspx#NthruR

In short, in order to create a new user type in:

New-Mailbox -Name <String> -Database <DatabaseIdParameter> -Password <SecureString> -UserPrincipalName <String> [-DisplayName <String>] [-FirstName <String>] [-Initials <String>] [-LastName <String>]

You might notice that if you simply type a string in for the password you’ll get an error:

New-Mailbox : Cannot bind parameter 'Password'. Cannot convert value "[given_password]" to type "System.Security.SecureString". Error: "Invalid cast from 'System.String' to ‘System.Security.SecureString'."

The reason for this is that the given password has to be a secure string type. In order to create it, type in the following (has to be separate from the previous command):


$Password = ConvertTo-SecureString '<string>' -AsPlainText –Force

After this you could refer to the given password as $Password.

We usually use this command in two different ways. The first one is to use a scripting language (my preference is Python) to generate the commands with different names. I have a list with the thousand most popular first names and the thousand most popular surnames. My script simply combines the two, giving me quite a lot of options. The second method is to name the users using a counter such as User 1; User 2;… User n and use a cycle in PowerShell to generate all required user names, such as:

$Password = ConvertTo-SecureString '<password>' -AsPlainText –Force

for ($i=0; $i -le 10; $i++)

{

New-Mailbox –Name <name>$i -Database <dbname> -Password $Password -UserPrincipalName <UPname> -DisplayName "<name> $i" -FirstName <firstname> -LastName $i

}

If someone doesn’t like PowerShell or doesn’t have it (e.g. Exchange 2003), the batch files I mentioned earlier used in active directory work just fine. After creating the users using those the mailboxes can be assigned to them fairly easily. In Exchange 2007, we have to start the “create new mailbox” process and select “existing users” in the first window.

This will show all users in AD that don’t have mailboxes. Fortunately multiselection is allowed so we don’t have to handle them one by one. Exchange 2003 doesn’t have this feature but there’s an easy workaround. Do a search using Exchange 2003’s Active Directory Users and Computers application for all users and multiselect them. Right clicking once will open the context menu where we can select “Exchange tasks” and “Create exchange mailbox” from there.

Finally, the command to add full access rights to a specific user so all mailboxes could be opened (and managed) from one outlook:

foreach ($sg in Get-StorageGroup) { if ((Get-ExchangeServer
$sg.Server).Domain.Equals("DomainName.com")) { get-mailboxdatabase
-storagegroup $sg.Identity | add-adpermission -user UserName
-accessrights GenericAll; } }

Some reports portend that the traditional roll of a SysAdmin will be changing drastically within businesses. No longer will they primarily procure servers, rack them, manage OSs, deploy patches and generally act as steward of the mundane “keep-the-lights-on” chores.

Concerning the traditional internal SysAdmin role, it is expected to exist in smaller numbers within a company, but in greater numbers withinin service providers.

Think about it for a moment, if an internal SysAdmin is merely spinning up server instances in a cloud or migrating a company’s ERP or project management system to a service provider, he no longer has to worry about the gritty details of high availability servers, application patches and database I/O. He merely negotiates a SLA that has the availability and performance he needs.

The internal SysAdmin now only worries about patching the applications on his side of the cloud that interface with the provider’s API, keeping the network up and responsive and other somewhat less intensive tasks. While those remaining internal tasks are certainly important things to keep up on, they’re not in the same category of premature-gray-hair-producing-tasks that the former were.

Does this not strike you as somewhat disconcerting? Are you thinking that much of your IT department’s current activities will be outsourced and will leave a significant number of people without jobs? The reality isn’t quite so grim depending on how accepting you are of change.

Inevitably, you will have to ask yourself (with apologies to The Clash) “Should I stay or should I go?” If you attempt to stay working as a SysAdmin internal to a business you will most likely have two broad possibilities.

First, you can hope that you’ll be retained in a central IT role. More probably you’ll be working as a broker between the company and an increasing population of service providers. See my previous blog post for more about that. It’s also not unreasonable to expect that there will be a need for a few true-blue SysAdmins (sans the brokerage duties) to manage customized systems, those too complex for absorption into the cloud and those that require more security than the cloud can provide. However, don’t count on even those jobs to stick around forever.

Second, you can seek to be moved into a closer relationship with an individual business unit. The saying “There are no IT projects, only business projects that have an IT component” is true enough to mention here. The technology projects that are directly valuable to the business’s activities  are the ones that are most closely tied with an individual department’s processes. For those components to work the best and ultimately make the most money for a business, the IT workers need to be focused intently on that department’s operations. That is not something that can be done from a distant, centralized vantage point, and executives have been saying that for some time. The move towards departmental IT is underway and will only continue to grow.

If you prefer those two options, then by all means stick it out. However, know that you’ll most likely be faced with playing a round of IT musical chairs with more internal applicants than open slots.

This brings us to the second set of possibilities for us SysAdmins: abandoning corporate IT in favor of working for a service provider. When your cheese get’s moved, grousing about it doesn’t make it grow wings and fly back to you, right?

As I see it, there are two broad categories of service provider that a SysAdmin could look to for employment. The first is the classic, high-level SaaS provider (the business model formerly known as an ASP).

I say “classic” because they’re nothing new. System administrators are not new to the idea of outsourcing certain components of their technology infrastructure. Most of us have web sites that are not hosted on our own machinery. Many of us have looked to outsourced anti-spam (Postini) or e-mail (Zimbra or Exchange) providers. Online office apps such as Zoho and Google Docs have been attracting people for years. Basecamp as a project management tool is loved by many a small or medium sized team. Do I even need to mention Sales Force?

I say “high-level” because in an environment like that, you’ll probably be working with managing the higher level application functions and not tweaking the grittier bits of the datacenter itself like the servers and networking equipment. That leads us to the second possibility for an external SysAdmin…

You could choose to work tending to the actual datacenters and server farms that are the building blocks for service providers. The EC2s, Terremark vClouds and Flexiscales of the world need some serious SysAdmin/Network Engineer brains to be able to manage their sprawling server farms, massive network designs and the method of virtualization used to create their commodotized wares. There’s only going to be more of a demand for their services, and thus more datacenters built that need managing.

So how’s your resume looking? You may want to take a quick look at it to see how you can improve it in the next few years now that you know what the future holds. Do you want to try and keep a internal IT position? Would you rather take flight to the other side of the cloud?

It’s worth noting that you don’t have to work for a “name brand” service provider like Postini or Zoho. There is plenty of pie to go around and there are plenty of smaller service providers out there. I submit my own self as an example. In the first half of 2010 I went through my own paradigm shift due to realizing the truth of what I’ve laid out in this and my previous blog post here on SysAdmin-Talk. I decided to walk away from my traditional position as an internal corporate IT SysAdmin and start my own hosted services company. If you’d like to read more about my personal journey, you can do so here.

Working at a medium sized service provider (or starting your own) may offer you the best of both worlds, with the hardware and networking challenges of managing datacenters (or at least a few cabinets in a collocation center) as well as the higher-level challenges of operating system and application management.

Analysts have stated that there will not be any lost need for the SysAdmin in the next 5 years. However, the places that we will find ourselves seeking employment from will be different. It does require a bit of a shift in your expectations, but if you can accept that, then you’ll have vibrant and exciting career ahead.

Are you ready for the shift? Have you already shifted jobs ahead of the curve?

To start with you will obviously require more than one Domain Controller in your Windows domain. In my case I have a “Primary” and “Secondary” domain controller called “NOOBS-DC1″ and “NOOBS-DC2″.

Transferring roles

RID, PDC or Infrastructure roles:

Start by opening Active Directory Users and Computers on the DC you want to change the role to. Right-click your domain name and select “Operation Masters” from the context menu.

Select the tab corresponding to the role you would like to transfer. Below this you should be able to see the name of the DC you are currently on, or connected to. Click the “Change” button to change the role over to the DC listed.

Confirm the change when asked, at which point you should receive a message stating that the procedure was successful.

Remember that this method can be used to transfer any of the RID (Relative ID), PDC (PDC Emulator) or Infrastructure roles. Just select the role you want to transfer by using the relevant tab.

Domain Naming Master role

Again, start on the DC that you would like to transfer this role to. Open Active Directory Domains and Trusts, then right-click the top level that reads “Active Directory Domains and Trusts” then select “Operations Master” from the context menu.

Check that the DC listed is the machine you would like to change the role to, then click “Change”.

Confirm the change – If all went well you should now receive a message stating the transfer was a success.

Note that you can also use the “Connect to Domain Controller” option in the context menu to connect to the DC you would like to transfer the role to. Access this by right-clicking “Active Directory Domains and Trusts” and then selecting the “Connect to Domain Controller” option. Here is what the Connect to Domain Controller window should look like:

Schema Master role

The Schema master role needs a little bit of extra work to change as the MMC snap-in you use is usually hidden. We will first need to register a .dll file before we are able to access this.

Again, start on the DC you would like the change the role to. Open a command prompt window and type in “regsvr32 schmmgmt.dll” then press Enter. You should receive a message stating the .dll was registered.

Now open a brand new MMC console. (Start -> Run -> type in “mmc” then press Enter). Select “File” then “Add/remove Snap-in” and click the “Add” button. You should see our newly added snap-in called “Active Directory Schema”. Select this option, then click “Add” and then “Close”. Click the “OK” button to go to back to your MMC.

Right-click “Active Directory Schema [your DC name]” and select “Change Domain Controller” if you are not already connected to the DC that you would like to inherit the role. Specify the DC’s name and confirm. In the screenshots below, I was defaulted to being connected to the DC1 server when loading the snap-in, but wanted to change to DC2 as this was the server that was going to be receiving the “Schema Master” role.

Right-click “Active Directory Schema [your DC name]” and select “Operations Master”. Finally, click the “Change” button to initiate the change. Confirm by click “Yes”, and you should receive a success message.

That should cover the basics of transferring your five FSMO roles between Domain Controllers. In the next part we’ll take a practical look at how to seize roles using the ntdsutil.exe command.