I’m attending Tech·Ed Europe 2010, are you?

Since I’ve shared some key information on Tech·Ed Europe 2010 earlier, I guess you’ve already concluded I’ll be attending Tech·Ed Europe this year.

Together with two colleagues (Roland Zenhorst and Dave Stork) I’ll be staying in a triple room at the abba Berlin hotel ****. We’re flying in on Sunday November 7, and flying back home to Amsterdam Airport on Saturday November 13.

Just like previous years, I’m eager to meet you all, so leave a comment or send me a contact note/mail when you want to meet up.

Vote for your favorite new Windows 8 features!

With Microsoft planning for the next version of the Windows Desktop, collectively referred to as Windows 8, promising to supersede Windows 7 and Windows XP together, some of us feel a need to chip in.

Here’s your chance! 

Together with Michael Pietroforte and a bunch of other Microsoft MVPs and insiders, we’re running a poll with features for the next version of the Windows Desktop.

Disclaimer
It is quite obvious that Microsoft won’t add all enhancements listed here, and for some features it is not very likely that they will consider them any time soon. But who knows, if those options receive enough votes, someone at Microsoft might get interested.

For your convenience, the features are listed below. Hoover over the description of the feature, to see the more elaborate description.

• New user interface
• Support for different form factors
• More modularity
• Third-party patch management
• Bare metal hypervisor
• Application virtualization
• Application streaming
• Windows Store
• Windows Restore Button
• Cloud APIs
• New authentication methods
• Instant-On
• Malware protection
• Better UAC
• Migration from Windows XP
• Better compatibility
• Better security
• Better performance
• Less hardware requirements
• Less bloat

Ready to vote?

 Vote

Descriptions and poll not readable or useable? Go to 4Sysops.

Participating blogs

Demonic Talking Skull – I’M A UC BLOG – markwilson.it – msigeek – Standalone Sysadmin – Techinch – Teching It Easy: with Windows – The Experience Blog – The things that are better left unspoken – The Windows Club – WindowsObserver – WindowsPro – Within Windows – 7 tutorials – 4sysops

Server Manager in Windows Server 2008 R2, Part 3

What started with the Configure your Server wizard and the introduction of Server Roles in Microsoft Windows 2000 Server, resulted in the tangible value of the Initial Configuration Tasks wizard (oobe.exe) and the Server Manager (servermanager.msc) in Windows Server 2008 and Windows Server 2008 R2.

Part 1 and Part 2 of this series focused on Server Manager Remoting and how to gain complete Remoting functionality with PowerShell Remoting in addition to Server Manager Remoting.

Now, in this part of this series, let’s look at a different (but in my opinion equally big) new feature in Server Manager in combination with several Windows Server Roles: Best Practices Analyzers.

About Best Practices Analyzers

Best Practices Analyzers, or BPAs as TLA-addicts like to call them, are not new to Microsoft products. Not even close, since the first Best Practices Analyzer, the Microsoft Exchange Server Best Practices Analyzer (ExBPA), was released in 2004…

Best Practices Analyzers (BPAs)

Part of Server Manager

The first thing that’s new is that Best Practices Analyzers are now part of Server Manager. When you click on a Server Role in the left navigation pane of Server Manager, in the Summary screen (in the main pane) you can scroll down to the Best Practices Analyzer section. Here you can:

• Start Best Practices Analyzer Scans using Scan This Role
• Review Best Practices Analyzer results
• Include and/or exclude specific Best Practices Analyzer results

The screenshot below shows the Best Practices Analyzers for the Active Directory Domain Services Role in Server Manager in Windows Server 2008 R2:

Extended to TechNet

When you view the properties of a Best Practices Analyzer result, either by double clicking a result in the results pane of by selecting the result and following the Properties link, you find more information on the result. Information per result include what was scanned, why it’s not compliant, what the risks are and how to fix the situation.

Below is an example of the “The PDC emulator master dc1.demo.ogd.nl in this forest should be configured to correctly synchronize time from a valid time source” result:

As you might notice, the information is pretty detailed. However, a link is displayed at the bottom of the screen with a hyperlink, promising even more information.

This hyperlink will make your browser (most likely Internet Explorer) visit a TechNet page. Offering clear formatting a more detailed step-by-step resolution path is offered. Actually, I don’t find the extra information the real punch. It’s the Community Content at the end of these TechNet pages, that might prove useful for many administrators.

Because, after working with the Exchange Best Practices Analyzer (ExBPA) for years, I found out not every BPA result results in a better working environment, in terms of usability, security or stability.

The Community Content feature on the TechNet BPA pages might contain warnings from other administrators, MVPs … well, actually anybody with a Windows Live ID!

Updated through Windows Update

There is no doubt in my mind, Microsoft will take the Best Practices Feedback. Even more, I don’t even doubt Microsoft to improve and expand on their Best Practice Analyzers.

As you might have already notice on your Windows Server 2008 R2 boxes, Microsoft is already actively offering update to the Best Practices Analyzer functionality, offering more Best Practices Analyzer scans and updated guidance. 

Also available in PowerShell

One last thing I’m excited about in terms of Best Practices Analyzers is the fact you can use PowerShell cmdlets from the Best Practices Analyzer PowerShell Module and Kick off Best Practices Analyzer Scans , review Best Practices Analyzer results and include and/or exclude specific Best Practices Analyzer results from the command line.

Combining this with PowerShell remoting you can make fun PowerShell scripts to perform Best Practices Analyzer scans and export them to Excel, XML and/or HTML format periodically for an intern to manage.

An example of such a script (without error checking!) would be:

invoke-command -computername RemoteServer -scriptblock{
import-module ServerManager
import-module BestPractices
get-bpamodel | invoke-bpamodel
get-bparesult Microsoft/Windows/FileServices | select Severity, Title,Resolution | ConvertTo-HTML | set-content “C:\filebpa.html”
copy C:\filebpa.html \\FileServer\data\BPAReports
}

Concluding

Best Practices Analyzers in Windows Server 2008 R2 are a part of Server Manager. The Exchange team has done a lot of pioneering in this area. When looking at the Exchange Troubleshooting Assistant (ExTrA), Exchange Pre-Deployment Analyzer (ExPDA) and the Microsoft Exchange Server Remote Connectivity Analyzer work this team has done and how this work has found its way into other Microsoft products and technologies, I think we’re in for some serious guidance to make our lives a whole lot easier. A good thing? Who knows…

Further reading

Updates for Best Practices Analyzer    
Best Practices Analyzer Updates for Server 2008 R2  
Microsoft releases a Best Practices Analyzer for Hyper-V 
Best Practices Analyzer for Hyper-V – First Impressions 
Best Practices Analyzer: Run it on your server roles, not your loved ones  
MS Announce Best Practices Analyzer update for RDS 
PRC08: Best Practices for Deployments and Upgrades – Takeaways 
Best Practice Analyzers for Windows Servers / Exchange  
Download details: Rules Update for Active Directory Domain Services Best Practice Analyzer for Windows Server 2008 R2 x64 Editions  
Best Practice Analyzer for Hyper-V – What does it check? 
Microsoft Forefront Threat Management Gateway (TMG) 2010 Best Practices Analyzer Tool 
AD: Rules Update for AD DS Best Practice Analyzer

Server Manager in Windows Server 2008 R2, Part 2

What started with the Configure your Server wizard and the introduction of Server Roles in Microsoft Windows 2000 Server, resulted in the tangible value of the Initial Configuration Tasks wizard (oobe.exe) and the Server Manager (servermanager.msc) in Windows Server 2008 and Windows Server 2008 R2.

Now, as I pointed out in Part 1, not all Server Manager functionality is available when you point it to a remote host. For these scenarios, and for repetitive tasks, you can use PowerShell.

PowerShell

One of the strong points of Windows Server 2008 R2 is the availability of PowerShell cmdlets, useable for managing most aspect of the Windows Server Operating System and built-in Roles and Features.

PowerShell Modules

Through the use of PowerShell modules, functionality can be added. The available modules are: (in alpabetical order)

*   Available by default in Windows Server 2008 R2
** Available by default, but not in Server Core installations

Of interest to this blogpost is the ServerManager PowerShell Module. Let’s start by importing the module to our PowerShell with the one-liner below: 

Import-Module ServerManager

Now, you can use the three cmdlets hidden inside this module:

1. Add-WindowsFeature
2. Get-WindowsFeature
3. Remote-WindowsFeature

PowerShell Remoting

Just like the Server Manager MMC Snap-in (servermanager.msc) is able to remotely manage servers, PowerShell know the same trick. This can be useful for the scenarios (described in Part 1) where you cannot use the GUI.

For instance, the following code snippet can be used to remotely add the DNS Server role to a Full installation of Windows Server 2008 R2 (specified with RemoteServer):

Invoke-Command -computername RemoteServer  -scriptblock {
Import-Module ServerManager
Add-WindowsFeature DNS
}

Concluding

Even though Server Manager in Windows Server 2008 R2 lacks some features when remotely managing Windows Server 2008 R2 installations, PowerShell Remoting can be used to fill in the blanks.

Further reading

Server Management in Windows Server 2008 R2 
What's New in Server Manager 
Windows Server 2008 R2's Improved Management Console 
Server Manager for Windows Server Core 2008 R2  
Why You Need Windows Server 2008 R2   
Managing Windows Server 2008 R2 using PowerShell 
574 Reasons Why We Are So Proud and Optimistic About W7 and WS08R2 
More PowerShell in R2 tricks

Server Manager in Windows Server 2008 R2, Part 1

What started with the Configure your Server wizard and the introduction of Server Roles in Microsoft Windows 2000 Server, resulted in the tangible value of the Initial Configuration Tasks wizard (oobe.exe) and the Server Manager (servermanager.msc) in Windows Server 2008 and Windows Server 2008 R2.

Server Manager opens when you close the Initial Configuration Tasks wizard. When you open Server Manager, it opens with an overview, as shown below:

Configuration items

It will show you the computer name, workgroup/domain information, IP addressing information and a quick view on remote management capabilities, windows firewall settings and windows update settings. Through the menu in the left pane, it offers quick access to roles and features, diagnostic tools (the event viewer, WSRM, performance monitor and the device manager) and the main configuration categories (task scheduler, windows firewall, services, WMI control and local users and groups).

Links and Wizards

Links are placed throughout the Server Manager to start corresponding GUI tools and/or wizards to change the information, if needed.

While, at first, both tools look the same on both Windows Server 2008 and Windows Server 2008 R2, under the hood, Server Manager is totally different. Let’s take a look at these differences, and how you can utilize the new features in everyday scenarios:

Server Manager Remoting

For the first time in the history of Microsoft Windows , the general configuration tool is capable of being used remotely. Not only can you use the Server Manager MMC Snap-in (servermanager.msc) on a Windows Server to point it to another Windows Server, the Snap-in is even part of the Remote Server Administration Tools for Windows 7.

When used remotely, however, Server Manager, lacks a couple of features, when you compare it to the Server Manager launched locally on a server. The table below shows the differences:

Functionality	Locally (Full install)	Remote (Full install)	Remote (ServerCore)
View main configuration items
View computer name
View domain/workgroup information
View IP addressing
View Remote Desktop settings
View Product ID and Activation status
View Windows Firewall settings
View Windows Update settings
Change main configuration items
Change computer name
Change domain/workgroup information
Change IP addressing
Configure Remote Desktop
Configure Server Manager Remote Settings
Enter product key and activate Windows
Change Windows Firewall settings
Configure Windows Updates settings
Run the Security Configuration Wizard
Configure IE Enhanced Security (IE ESC)
Server Roles and Features
View installed Roles
View installed Features
Add Roles
Add Features
Remove Roles
Remove Features
Check for new Roles
Manage Roles remotely
Manage Features remotely
Run Best Practices Analyzer scans
View Best Practices Analyzer results
Diagnostics
Event Viewer
Windows System Resource Manager	*	*
Performance Monitor
Device Manager (read-only)
Device Manager
Configuration
Task Scheduler
Windows Firewall with Adv. Security
Services
WMI Control
Local Users and Groups
Storage
Disk Management

* Only applicable when the Windows System Resource Manager feature is installed.

Concluding

Server Core Remoting offers functionality to manage servers remotely after you’ve set them up to be a part of your network and have assigned them roles.

With access to the Windows System Resource Manager being the only difference between remotely managing a Server Core installation and remotely managing a Full installation, it is safe to say Server Manager facilitates managing Server Core installations remotely. You could be managing Server Core installations without even noticing the difference from a management perspective. From a security, power and resource consumption perspective however, you’d notice the difference!

Further reading

Server Management in Windows Server 2008 R2 
What's New in Server Manager 
Windows Server 2008 R2's Improved Management Console 
Server Manager for Windows Server Core 2008 R2  
Why You Need Windows Server 2008 R2   
Windows Server 2008 R2 – Whats Special there???

Four in a row

Four years ago, on June 26th 2006, I posted the first piece of writing to this blog space. Little did I know back then the adventure I was getting myself into…

Looking back, it’s not just the experience of writing stuff down for the whole world to see. It’s not just the half million pageviews on this blog.  It’s the feedback I get from readers like you, from organizations like Microsoft and (since two years) the feedback I get from fellow Microsoft MVPs.

At times, it felt hard to come up with something interesting to tell you all about. With a personal goal to write at least one blogpost per week (on average) it’s sometimes hard.  Some periods I didn’t visit any customers and couldn’t write about these experiences.

Over the past four years, however, I came up with 243 posts (not including this one) which exceeds my goal.

In the past four years you have posted 133 comments. Other bloggers have posted  358 trackbacks. To me it’s an honor that so many of you made an effort (registering, then reloading the page and then commenting) to comment on a post. Also, the links from other blogs feel like a compliment. Not just casual bloggers tend to link back, but we’re also receiving backlinks from the ‘Ask the Directory Services team’ blog and ‘The Experts Community’…

Thank You!

ADMT 3.2 Now Available!

Windows Server 2008 R2 was released on October 22nd 2009. With a slew of new Active Directory features, the newest incarnation of Windows Server was appealing to many customers. But not to some customers. One thing that stood in their way was the inability to restructure Active Directory domains and forests. Much needed functionality in their line of business, where mergers, acquisitions and divestitures occur often or even are their line of business.

The challenge was no suitable version of the Active Directory Migration Toolkit (ADMT) was available to support some of these scenarios. ADMT 3.1 does not support installation on Windows Server 2008 R2 or an Active Directory domain containing Windows Server 2008 R2 Domain Controller as its source domain.

Now, almost a year after Windows Server 2008 R2 RTM'ed and a little over a year since Microsoft acknowledged the problem, an appropriate version of the Active Directory Migration Tool is available: version 3.2 supports Windows Server 2008 R2 in all scenarios.

Downloads

Download ADMT version 3.2 here.
It’s available in English, Chinese (Simplified and Traditional), French, German, Japanese, Portuguese (Brazil), and Spanish.

The 263-page Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains for use with version 3.2 is available here. It’s available in the same languages as mentioned above.

Further reading

ADMT 3.1 and Windows Server 2008 R2
Using ADMT 3.1 to migrate to Windows Server 2008 R2 domains
ADMT 3.1 and Windows Server 2008 R2

Server Core Anytime Upgrades

Windows Vista had a neat trick up its sleeve, that allowed admins to change the Vista SKU without the need for reinstallation or installation media. One could, for instance, 'transition' a Windows Vista Home Basic installation to Windows Vista Home Premium, Business, Ultimate or Enterprise. This functionality is called Windows Anytime Upgrade (WAU)

Windows 7 and Windows Server 2008 R2 also have this functionality built-in. (Unfortunately Windows Server 2008 does not.)

So, let’s look how Windows Anytime Upgrades work on Server Core installations of Windows Server 2008 R2.

Windows Anytime Upgrade FAQ

So let’s look at Anytime Upgrades a bit deeper:

Q: Is a Windows Anytime Upgrade the same as an In-place Upgrade?
A: No. In-place Upgrades can be performed to upgrade a previous version of Windows to a more recent version of Windows. Anytime Upgrades are only possible between the same version of Windows.

Q: Are Windows Anytime Upgrades possible between architectures, e.g. between x86 and x64?
A: No. Anytime Upgrades are only possible between SKUs of the same architecture.

Q: Do I need to download a Windows Update for Windows Anytime Upgrades?
A: No you don’t. The only network communication is for Windows activation.

Q: Can I revert back after a successful Windows Anytime Upgrade?
A: No, Windows Anytime Upgrades are one-way processes.

Q: Can I perform Windows Anytime Upgrades in Windows Server 2008?
A: No. This feature is not available in Windows Server 2008.

Q: How much time does a typical Windows Anytime Upgrade take?
A: Most of the time will be taken up by the two system restarts.The rest of the process would normally take a couple of (Microsoft) minutes.

Q: Can the server be a Domain Controller?
A: No, the server cannot be a Domain Controller or Certificate Authority at the time of Windows Anytime Upgrade.

Q: Can I use Windows Anytime Upgrade to change between (OEM, MAK, KMS) productkeys?
A: No, if you want to change the licensing channel, use the slmgr.vbs tool   

Windows Anytime Upgrade paths

The first thing to look at is the Windows Anytime Upgrade paths available, based on the installed Windows Server SKU. The table below shows these paths for the available Server Core flavors of Windows Server 2008 R2:

Windows Anytime Upgrade commands

To Anytime Upgrade a Server Core installation of Windows Server 2008 R2, use the following commands.

First, determine the SKU your Server Core installation is running. Use the following command:

dism.exe /online /Get-CurrentEdition

Then, you’re ready to check for possible target SKUs. Run:

dism.exe /online /Get-TargetEditions

Finally, to initiate an upgrade, run:

dism.exe /online /Set-Edition:Edition /ProductKey:ProductKey

Where Edition can be ServerDatacenter or ServerEnterprise and ProductKey is the 25-digit productkey, notated with dashes. For instance: ABCDE-FGHIJ-KLMNO-PQRST-UVWXY.

Windows Anytime Upgrade Benefits

After you perform a Windows Anytime Upgrade, you reap the following benefits:

• Enterprise Edition and Datacenter Edition offer the Failover Clustering feature.
  When you’re looking to convert a Standard Edition installation into a cluster, however, the Anytime Upgrade feature is for you. Check, however, whether the application, role or feature can handle an Anytime Upgrade.
  
• Enterprise Edition and Datacenter Edition offer more flexible ways to license virtual machines running on the installation. Standard Edition allows for one virtual licensed Windows installation. Enterprise Edition allows for up to four virtual licensed Windows Installations. Datacenter allows for unlimited virtual licensed Windows Installations.

Concluding

Windows Anytime Upgrades can be useful for Windows Server installations to reap the benefits of an upscale SKU. For Server Core installations, these benefits aren’t really big.

One day, perhaps, the Anytime Upgrade functionality will be of major importance to Server Core installations. This might be the day when Anytime Upgrades can be used to switch from Server Core installations to Full installations and vice versa.   

Related posts

Server Core Roles and Features in 2008 R2 
Core flavors of Windows Server 2008  

Further reading

Upgrading Windows Server 2008 R2 without media 
Windows Anytime Upgrade: frequently asked questions    
Upgrading Windows Server 2008

Speaking engagements for June

June 2010 is poised to be an incredibly prolific month this year for me.

Not only will I be celebrating my 4th year of blogging (right here on DirTeam), but I’m also invited to some venues to help out, co-organizing an event and even doing some live TV stuff.

Exciting!

TechNet Deep Dive Bussum, the Netherlands

June 1, 2010 In Person event More information

As I already mentioned before I’ll be attending the TechNet Deep Dive event in the Netherlands on June 1. Between sessions I’ll be at one of the Ask the Experts desks. To start of this day in style I’ll be having breakfast with John Craddock from 7:30 AM.

Experts Live Nijkerk, the Netherlands

June 16, 2010 In Person event More information

On June 16, I’m presenting at the free Experts Live event. I’m also the track owner for the Infrastructure track, that features a Windows 7 session (by Raymond Comvalius), A Forefront Identity Manager session (by Jorge de Almeida Pinto) and a Forefront Threat Management Gateway / Unified Access Gateway session (by Martijn Bellaard).

My 75-minute session will focus on Management improvements in Windows Server 2008 R2.

VirtualStudy Conference conf2010.virtualstudy.pl

June 19, 2010 Online event More information

On June 19, I’m presenting a LiveMeeting as part of the free 2010 VirtualStudy.pl Conference. With a slew of Eastern European MVPs and a couple of Speaker household names (Andy Malone) this event features an IT Pro track, a SQL track and a Dev track.

I’ll be presenting a 75-minute session on best practices surrounding Active Directory and server hardware virtualization with Hyper-V.

NGN Live TV livestream.com/ngnnl

June 23, 2010 Live TV with chat  More information

If you instead prefer to watch me, while I’m casually discussing general IT news, you might want to tune in to NGN Live Expert TV on June 23. Of course, Windows Server 2008 R2 will be one of the subjects that’ll receive some major attention during this 20-minute live talk.

Transitioning your Active Directory to Windows Server 2008 R2

You might be running Windows Server 2003 (R2) and Windows Server 2008 Domain Controllers at the moment and you're looking to replace these servers with Windows Server 2008 R2 Domain Controllers to utilize the new features of Windows Server 2008 R2.

You might also be looking to replace your aging Windows Server 2003 (R2) and Windows Server 2008 Domain Controllers with spanking new Windows Server 2008 R2 Domain Controllers, while keeping your Active Directory running smoothly.

Transitioning Active Directory is the most common way to migrate Active Directory. This post intends to help you with this transition in a structured, balanced and thorough way and describes:

• Ways to migrate 
• Reasons to transition
• Steps to transition
  • Before you begin
  • Prepare your Active Directory environment
  • Install the first Windows Server 2008 R2 Domain Controller
  • Install additional Domain Controllers
  • Check proper installation, replication and updates
  • Take care of FSMO roles and Global Catalog placement
  • Demote your old Domain Controllers
  • Raise the domain functional level
  • Raise the forest functional level
  • Enable Active Directory Optional Features
  • Run the Active Directory Best Practices analyzer
• Concluding

Ways to migrate

Upgrading your Windows Server 2003 (R2) / 2008 Active Directory environment to Windows Server 2008 R2 can be done in three distinct ways:

• In-place upgrading
  x64 installations of Windows Server 2003 (R2) and Windows Server 2008 can both be upgraded in-place to Windows Server 2008 R2, as long as you keep the following in mind:
  • The Windows Server 2003 patch level should be at least Service Pack 2
  • Standard Edition can be upgraded to both Standard and Enterprise Edition
  • Enterprise Edition can be upgraded to Enterprise Edition only
  • Datacenter Edition can be upgraded to Datacenter Edition only
  • Foundation Edition (2008 only) can be upgraded to Standard Edition only
  • Server Core installations can only be upgraded to Server Core installations

• Transitioning
  Migrating this way means adding Windows Server 2008 R2 Domain Controllers to your existing Active Directory environment. After successfully moving the Flexible Single Master Operations (FSMO) roles you can simply demote the previous Domain Controllers, remove them from the domain and throw them out of the window.
  Transitioning is possible for Active Directory environments which domain functional level is at least Windows 2000 Native.
   
• Restructuring
  A third way to go from Windows Server 2003 (R2) / 2008 Domain Controllers to Windows Server 2008 R2 Domain Controllers is restructuring your Active Directory environment. This involves moving all your resources from one (Windows Server 2003) domain to a new and fresh (Windows Server 2008 R2 ) domain. Tools like the Active Directory Migration Tool (ADMT) are priceless in these kind of migrations.

Reasons to transition

I feel transitioning is the middle road between the two other ways to migrate to Windows Server 2008 R2:

• Restructuring means filling a new Active Directory from scratch
• In-place upgrading means you're stuck with the same hardware and limited to certain upgrade paths
• Transitioning means you get to keep your current Active Directory lay-out, contents, group policies and schema. Transitioning also means moving to new machines, which can be dimensioned to last another three to five years without trouble.

Transitioning is good when:

• You worked hard to get your Active Directory in the shape it's in.
• Your servers are faced with aging.
• In-place upgrading leaves you with an undesired outcome
  (for instance Server Core or Enterprise Domain Controllers)
• You need a chance to place your Active Directory files on different partitions/volumes.

When done right your colleagues might not even suspect a thing! The downside is you need to know exactly what you're doing, because things can go wrong pretty fast. that's why I wrote this post.

Steps to transition

Transitioning to Windows Server 2008 Domain Controllers consists of the following steps:

Before you begin

Avoid common mistakes
There is a very good Microsoft Knowledge Base article on Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain, written by community experts.  I suggest you read it (twice). Most of the contents also apply to transitioning to Windows Server 2008 R2.

Plan your server lifecycle
It's not uncommon for a Domain Controller to sit on your network for a period of five years. I believe you should take this in mind when selecting and buying a server. You should plan your partitions (or volumes) carefully and place the Active Directory files on separate volumes when your needs justify it. The Windows Server catalog helps you pick systems that will run Windows Server 2008 R2 with ease.

Assess your readiness
Microsoft has kindly provided a tool to scan systems to assess whether systems are capable of running Windows Server 2008 R2, whether drivers are available (either from Microsoft update or on the installation media) and what problems you might encounter when deploying Windows server 2008 R2. I recommend checking your systems with this tool, which is called the Microsoft Assessment and Planning Solution Accelerator (MAP for short).

Map out your 64bit transition
Since Windows Server 2008 R2 is only available in 64bit flavors, you’ll need to make sure every aspect of your Active Directory Domain Controller implementation is 64bit ready. The MAP tool will not sort everything out for you, so you will have to dive into stuff like anti-malware, backup, software for uninterruptible power supplies, monitoring, systems management, time synchronization and your licensing (VAMT/ MAK / KMS) solution.

Review the considerations for upgrading
Active Directory Domain Services in Windows Server 2008 R2 breaks some functionality present in previous versions of Active Directory. For instance, NT 4.0 compatible encryption is off by default on Windows Server 2008 R2 Domain Controllers. Review these considerations and determine whether they are show stoppers in your environment.

Backups
Make backups of all your Domain Controllers and verify you can restore these backups when needed.

Documentation
It is a good thing to know exactly what you're migrating. When things go wrong you might need to be able to revert back to the old situation. This might require the Directory Services Restore Mode (DSRM) password and credentials for service accounts, which might not be written down anywhere. In multiple Domain Controller, multiple domain, multiple forest and multiple sites scenarios it's very wise to make a table containing the relevant information per Domain Controller in terms of Flexible Single Master Operations (FSMO) roles, Global Catalog placement, domain membership, site membership, replication topology, routing tables, IP addressing, etc.

Communication
When done right your colleagues might not even suspect a thing, but it's important to shed some light on what you're doing. (Make someone) communicate to the end users that you're going to mess with the core of their infrastructure. This might result in colleagues understanding you're (really) busy and might also result in problems being reported fast. Both are good things if you'd ask me...

Prepare your Active Directory environment

Before you can begin to introduce the first Windows Server 2008 R2 Domain Controller into your existing Active Directory environment, you first have to prepare the Active Directory.

Microsoft provides two tools to facilitate this preparation. Depending on your current Active Directory environment you need to use either one of them:

You need to run the following commands on the following Domain Controllers in your current Active Directory environment:

                               * Optional when you want to deploy Read Only Domain Controllers.

After preparing your Active Directory for Windows Server 2008 R2 be sure to check the process. Breadcrumbs to failures may be found in the event viewer, but real men will check the adprep.log files.

Allow sufficient time for proper replication to all Domain Controllers. (In large environments with specific replication needs this might take hours.) When you feel all changes have been replicated use the repadmin tool to check and optionally troubleshoot Active Directory replication. The following one-liner will show you the schema version per Domain Controller:

repadmin /showattr * "cn=schema,cn=configuration,dc=domain,dc=tld" /atts:objectVersion

When all your Domain Controllers report Schema version 47, you’re good to go with the next steps.

Install the first Windows Server 2008 R2 Domain Controller

You could already start installing Windows Server 2008 R2 on a fresh box and make it a member of the domain, while preparing your Active Directory. Taking care of an update, a backup and an anti-malware infrastructure might take some time, so why not spend it wisely?

When you're done preparing your Active Directory and checking the replication process, you can safely go ahead installing the first Windows Server 2008 Domain Controller by promoting a Windows Server 2008 box to a Domain Controller, using dcpromo.exe.

When running dcpromo.exe make sure you select to make this Domain Controller an extra Domain Controller for the Active Directory domain you're transitioning. Type a secure password for Directory Services Restore Mode (DSRM).

Tip:
Write down the the Directory Services Restore Mode (DSRM) password.

Since each Active Directory Domain Controller stores a copy of the Active Directory information, like users, computers, etc. and the NETLOGON and SYSVOL shares, your new Windows Server 2008 R2 Domain Controller will be open for business after you restarted it to complete the wizard.

Install additional Domain Controllers

Installing additional Windows Server 2008 R2 Domain Controllers is as easy as purchasing them, licensing them, installing them and promoting them. There's really nothing to it: Once you've introduced the first Windows Server 2008 R2 Domain Controller you know how to do it.

If you find installing loads of Domain Controllers is a tedious job you might want to promote servers to Domain Controllers using answer files. When Domain Controllers need to be placed in locations with limited connectivity or bandwidth constraints you might want to explore the Install from Media (IFM) possibilities.

Check proper installation, replication and updates

It is a best practice to review the logs to identify any problems that might have occurred during the promotion. The logs to scrutinize specifically are:

• dcpromo.log
  All the events regarding the creation and removal of Active Directory, SYSVOL trees and the installation, modification and removal of key services
• dcpromoui.log
  all the events from a graphical interface perspective

Also check the event viewer.

Allow sufficient time for proper replication to all Domain Controllers. (In large environments with specific replication needs this might take hours.)

Since Windows Server 2008 updates for Server Roles are targeted towards Windows Servers, actually having the role installed. After you’ve promoted your Windows Servers, make sure you’re running Windows Update on them to make sure no nasty bugs in the Active Directory Domain Controller role remain.

Take care of FSMOs and GCs

Using the Active Directory Sites and Services MMC Snap-in make new Windows Server 2008 R2 Domain Controllers Global Catalog servers appropriately.

Also transfer Flexible Single Master Operations (FSMO) Role to appropriate servers. You can use the Graphical Interface to move the Flexible Single Master Operations (FSMO), or go full out on the command line using ntdsutil.

In multiple Domain scenarios Jorge has a good rule of thumb on Global Catalogs and the Infrastructure Master Flexible Single Master Operations (FSMO) Role. Either:

• Don't make the Domain Controller holding the Infrastructure Master Flexible Single Master Operations (FSMO) Role a Global Catalog server;
• Make all Domain Controllers Global Catalog servers.

When your environment includes Microsoft Exchange Server reboot a Domain Controller after making it a Global Catalog server. Microsoft Exchange communicates with Active Directory through Global Catalogs using MAPI. Although the Active Directory Sites and Services MMC Snap-in doesn't ask for it you need to restart a Domain Controller at least one time after making it a Global Catalog before it starts talking MAPI.

Make sure your Windows Server 2003 (R2) / 2008 Domain Controllers are no longer clinging on to any of the Flexible Single Master Operations (FSMO) Roles using the graphical user interface, or the following command using netdom.exe:

netdom.exe query fsmo

Demote your old Domain Controllers

I've seen Domain Controllers became the prostitutes of the server room in many environments. Any software that didn't require a dedicated server or was deemed highly dependent on the Active Directory was installed on the Domain Controller. When you're one of the administrators treating their Domain Controllers like that you're going to have a hard time demoting your Domain Controllers. Testing demotions in a separate (virtual) testing environment could give your a clear picture on the behavior of your  ex-Domain Controllers though! Remember: “Everyone has a test environment, not just everyone has a production environment…”

From my personal experience I can tell you it's not recommended to demote a Domain Controller when it has Exchange Server or Internet Information Services installed after it was promoted. You're going to have to find another box to install these services on.

When your Windows Server 2003 (R2) / 2008 Domain Controllers are also Domain Name System (DNS) servers it is recommended to change the DNS zones into Active Directory Integrated DNS zones (when possible) so they get replicated to any Domain Controller running the DNS service. Installing the DNS Server role on a Windows Server 2008 R2 Domain Controller would then suffice to migrate DNS settings. Be sure to change the DNS information on your other servers and workstations, before removing DNS servers from your network.

You can safely demote a Domain Controller using the dcpromo.exe command. If you're unsuccessful you might want to try to remove the server from Active Directory the hard way, which Jorge describes here. (leaving out the percussive maintenance option though)

Raise the domain functional level

After you've successfully demoted the last Windows Server 2003 (R2) / 2008 Domain Controller for a specific domain (or you don't feel the need to ever add pre-Windows Server 2008 R2 Domain Controllers to your Active Directory environment) you're ready to raise the Domain functional level of that domain.

Upgrading the domain functional level to Windows Server 2008 R2 adds two features to your environment:

1. Authentication Mechanism Assurance
   This mechanism adds information to the user’s Kerberos token on the type of authentication used. This allows administrators to modify group membership based on how the user authenticates. For example, a user can have access to different resources if they log in with a certificate versus when they log in with just their username and password.
     
2. Automatic SPN management
   In the past administrators regularly used Active Directory user accounts as service accounts for Exchange Server, SQL Server and Internet Information Services (IIS).
   Managed Service Accounts (MSAs) can now be used since Windows Server 2008 R2 and this features allows for automatic SPN management, one of the two main benefits of these accounts.

Note:
Raising the functional level is a one way procedure. Once you've raised your forest functional level there's no way to return to the previous forest or domain functional levels.

Raising the domain functional level in Windows Server 2008 R2 looks remarkably similar to raising the domain functional level on Windows Server 2003:

1. Log on to the Domain Controller holding the PDC emulator FSMO role with a user account that is a member of the Domain Administrators group..
2. Open Active Directory Domains and Trusts.
3. In the console tree, right-click the domain for which you want to raise functionality, and then click Raise Domain Functional Level.
4. In Select an available domain functional level, click Windows Server 2008 R2, and then click Raise.

Raise the forest functional level

After you've successfully upgraded the domain functional level of all the domains in your Active Directory forest you're ready to upgrade the Forest functional level. This will not add any features, but will result in all domains that are subsequently added to the forest will operate at the Windows Server 2008 R2 domain functional level by default and allows for enabling the Active Directory Recycle Bin feature.

Note:
Raising the functional level is a one way procedure. Once you've raised your forest functional level there's no way to return to the previous forest or domain functional levels.

To upgrade the forest functional level to Windows Server 2008 R2 perform the following actions:

1. Log on to the Domain Controller of the forest root domain holding the PDC Emulator FSMO role with a user account that is a member of the Enterprise Administrators group.
2. Open Active Directory Domains and Trusts.
3. In the console tree, right-click Active Directory Domains and Trusts, and then click Raise Forest Functional Level.
4. Under Select an available forest functional level, click Windows Server 2008 R2, and then click Raise.

Alternatively you can use the following two PowerShell commands:

Import-Module Active Directory
Set-ADForestMode domain.tld  Windows2008R2Forest

Enable Active Directory Optional Features

When your Active Directory environment runs the Windows Server 2008 R2 Forest Functional Level you can enable the Windows Server 2008 R2 Active Directory Optional Feature: Active Directory Recycle Bin.

To enable this feature, run the following simple PowerShell one-liner:

Enable-ADOptionalFeature –Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=domain,DC=tld' -Scope ForestOrConfigurationSet -Target 'domain.tld'

Run the Active Directory Best Practices analyzer

Another cool new feature in Windows Server 2008 R2 is the Active Directory Domain Services Best Practices Analyzer (BPA). Using the BPA you can scan your Active Directory infrastructure for compliance with the Best Practices.

The Active Directory Domain Services BPA can be run using the Server Manager or using the PowerShell Cmdlets. To run the scan from Server Manager perform the following steps:

Tip!
Server Manager can be used to scan a local or remote computer. To scan a remote computer, simply use the Connect to Another Computer option in Server Manager.

1. Logon to a domain controller that has Windows Server 2008 R2 installed.
2. Open Server Manager.
3. In the console tree of Server Manager, expand the Roles node, and then select the Active Directory Domain Services role.
4. Scroll down to the Best Practice Analyzer section.
5. Click on the Scan This Role link on the right.

Using your common sense, make the configuration changes for the noncompliant settings listed as warnings and errors.

Concluding

Transitioning your Active Directory to Windows Server 2008 R2 seems as easy as running adprep.exe or adprep32.exe and installing Windows Server 2008 Domain Controllers. It might be in small shops with one single Domain Controller in one single Active Directory domain in its own forest with one single Active Directory site.

In larger environments de sure to check whether what you're doing is successfully installed, performed and replicated before you screw up your Active Directory environment though!

Related posts

Considerations when upgrading your Active Directory to Windows Server 2008 and 2008 R2 
An early look at new Active Directory features

Further reading

Active Directory in Windows Server 2008 and Windows Server 2008 R2  
Migrate Server Roles to Windows Server 2008 R2    
Migrating to Active Directory 2008 R2    
Migrating to Active Directory 2008 R2 
Migrating an Active Directory Domain Controller from Windows 2000 to Windows 2008 R2 
Migrate Active Directory from 2003 R2 to 2008 R2 Server Core 
Windows Server 2008 R2 Migration Guide – Replacing Existing Domain Controllers 
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains (DOC)    
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains (WEB)    
Upgrading Domain Controllers: Microsoft Support Quick Start for Adding Windows Server 2008 or Windows Server 2008 R2 Domain Controllers to Existing Domains    
Running ADPREP To Upgrade the AD Forest/Domain

Considerations when upgrading your Active Directory to Windows Server 2008 and 2008 R2

While upgrading your Active Directory Domain Controllers, Domain Functional Level(s) and Forest Functional Level to Windows Server 2008 and Windows Server 2008 R2 offer additional functionality compared to previous versions, also a couple of caveats exist, that I think you should be aware of.

In this blogpost:

• NT 4.0 Compatible Encryption
• Going 64 (bit)
• Getting acquainted with the Command-line
• Limited ways to migrate to Windows Server 2008 R2
• Deploying Server Core Domain Controllers
• Virtualizing Domain Controllers

Windows Server 2008 and Windows Server 2008 R2 Domain Controllers have a new more secure default for the security settings named “Allow cryptographic algorithms compatible with Windows NT 4.0”.

When you promote a server to a Domain Controller, a screen containing this message is displayed, right after the Welcome screen:

This policy is configured to prevent Windows operating systems and third-party clients from using weak cryptography algorithms to establish NETLOGON security channels to Windows Server 2008-based domain controllers.

While this does not seem like a big deal, it might be in the light of the Active Directory Migration Tool (ADMT). Without the ability to build a trust between the source and target domain, one cannot migrate objects from a Windows NT4 domain. You never hope to encounter a Windows NT 4.0 environment in a merger, acquisition, or divestiture situation, but one can never be sure…

Also, you may experience problems in environments merely containing Windows Server 2008 and Windows Server 2008 R2 Domain Controllers when you configure pre-Windows Vista SP1 clients to join the domain though Windows Deployment Services or the Microsoft Deployment Toolkit (MDT). For Windows XP and Windows Server 2003 an update is available to correct this problem.

Now, of course, not migrating to Windows Server 2008 (R2) is a bit excessive. When you’re running into problems and don’t mind the loosened security settings, you can always (temporarily) turn on the “Allow cryptographic algorithms compatible with Windows NT 4.0” setting on every Windows Server 2008 and Windows Server 2008 R2 you need it. Perform the following steps:

1. Log on to a Windows Server 2008-based or Windows Server 2008 R2-based Domain Controller.
2. Click Start, click Run, type gpmc.msc, and then click OK.
3. In the Group Policy Management console, expand Forest: DomainName, expand DomainName, expand Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.
4. In the Group Policy Management Editor console, expand Computer Configuration, expand Policies, expand Administrative Templates, expand System, click Net Logon, and then double-click Allow cryptography algorithms compatible with Windows NT 4.0.
5. In the Properties dialog box, click the Enabled option, and then click OK.

After this step restart the netlogon service.

When you want to put the new default security settings into effect, perform the same steps, but click the Disabled option in step 5.

Windows Server 2008 R2 is only available in 64bit flavors. So, when transitioning from 32bit Domain Controllers to 64bit Domain Controllers, you’re bound to encounter some interesting challenges.

The first challenge is to prepare your Active Directory environment for Windows Server 2008 or Windows Server 2008 R2. To prepare an Active Directory environment for newer Domain Controllers, you’d run adprep.exe on the Domain Controller running the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role.

However, when preparing your 32bit Windows Server 2003 (R2) Active Directory environment for Windows Server 2008 x64-based Domain Controllers, you’d need to run the adprep.exe from the Windows Server 2008 x86 DVD. Luckily, the adprep.exe on the trial DVD will suffice for this purpose.

Preparing a 32bit Windows Server 2003 (R2) or Windows Server 2008 Active Directory environment for Windows Server 2008 R2 is a different story. You’ll need to run adprep32.exe in this case. It is located on the Windows Server 2008 R2 DVD in the same folder as adprep.exe. (This version of adprep.exe is x64 only.)

Also, when deploying Windows Server 2008 R2 Domain Controller, you should first check whether all the tools and programs you’re using in the current environment are 64bit- and Windows Server 2008 R2 ready. This includes anti-malware protection software, backup software, software for managing and responding to Uninterruptible Power Supply events, 3rd party management tools, and monitoring tools.

When migrating to Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers and their respective Domain and Forest Functional Levels, prepare for some command-line stuff.

First off, to check for proper replication of the Active Directory preparation you can’t use the graphical replmon.exe tool. This tool is no longer available. Instead, you’ll need to use the command-line repadmin.exe tool.

Furthermore, most of the more advanced features, available when using Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers and the Windows Server 2008 and Windows Server 2008 R2 Functional Levels, is only available on the command-line.

For instance, compacting your Active Directory database(s), managing fine-grained password policies, working with Active Directory snapshots, offline domain join, creating IFM media with SYSVOLs, enabling and using the Active Directory recycle bin and managing Managed Service Accounts (MSAs) is only available on the command-line (when using only built-in tools).

Read the series:

• Active Directory Domain Services Command Fu, Part 1   
• Active Directory Domain Services Command Fu, Part 2  
• Active Directory Domain Services Command Fu, Part 3  
• Active Directory Domain Services Command Fu, Part 4 
• Active Directory Domain Services Command Fu, Part 5 
• Active Directory Domain Services Command Fu, Part 6  

While this blogpost was written, no suitable version of the Active Directory Migration Tool (ADMT) existed to restructure Active Directory environments to Windows Server 2008 R2.

Restructuring is one of three ways to migrate to a next version of Windows Servers as Domain Controllers. In-place upgrading and transitioning are the other two ways. With in-place upgrading a next version of Windows Server is used to upgrade a Domain Controller directly without reinstalling. Transitioning means adding additional Domain Controllers with a new version of Windows Server, side by side to existing Domain Controllers with the purpose of phasing out the old Domain Controllers.

When you want to restructure your Active Directory to Windows Server 2008 R2 you will either need to wait for the Active Directory Migration Tool (ADMT) version 3.2, or restructure to an Active Directory infrastructure, based upon Windows Server 2008 Domain Controllers and in-place upgrade or transition to Windows Server 2008 R2 Domain Controllers from there.

Server Core installations are optimized installations of Windows Server. This installation option was introduced with Windows Server 2008.

While Server Core Domain Controller are highly optimized, they also pose a problem when you’re mixing Windows Server 2008-based Server Core Domain Controllers, Windows Server 2008 R2-based Server Core Domain Controllers and the new Active Directory Administrative Center. (ADAC)

The Active Directory Administrative Center (ADAC) uses the Active Directory Web Service to communicate with Active Directory Domain Controllers. This service runs on top of the .Net framework.

The problem is Windows Server 2008-based Server Core Domain Controllers, don’t support the .Net framework. Therefore, you can’t use the Active Directory Administrative Center to manage these Domain Controllers. Of course, Windows Server 2008 R2-based Domain Controllers will still replicate changes, but your Domain Controllers will not be equal, which leads to a suboptimal management experience (over time).

Another difference between Server Core installations of Windows Server 2008 and Windows Server 2008 R2, is the different management tools available. Where Windows Server 2008 offers the ocsetup.exe and oclist.exe tools, Windows Server 2008 R2 offers dism.exe, which is more powerful. 

Read more in: Some Server Core Domain Controllers heading for a dead end street 

Hyper-V is a new server role, introduced in Windows Server 2008. Along with Hyper-V, the Server Virtualization Validation Program (SVVP) came to life. Virtualization was already a hot topic in many enterprises by that time, but the popularity of virtualizing the datacenter rose further.

While virtualized Domain Controllers (whether they’re Server Core or Full installations) offer significant benefits in terms of flexibility, scalability and disaster recovery, they’re also the heart of the infrastructure and should be deployed wisely.

Therefore, follow these best practices when virtualizing Domain Controllers using Hyper-V clusters:

• Deploy at least two Domain Controllers per domain and keep one physically deployed Domain Controller per domain;
• Apply minimum patchlevels;
  (specific hotfixes exist for Windows 2000 Server and Windows Server 2003)
• Install the Integration components;
• Provide adequate Time Synchronization;
• Never save state or pause a Domain Controller;
• Don't use undo disks, differencing disks or snapshots;
• Backup and restore Domain Controllers the right way;
• Use Fixed-Sized VHDs;
• Use different disks for Active Directory files;
• Use Sysprep.exe instead of NewSID.exe;
• Don’t make your Domain Controllers highly available within Hyper-V;
  (use Hyper-V R2 when you want to make your Domain Controllers highly available)
• Secure your virtual Domain Controllers like you would physical Domain Controllers, but at a minimum use syskey.exe in virtualized Domain Controllers;
• Perform Offline P2V Migrations when virtualizing an existing Domain Controllers;
• Don’t perform storage migrations on live Domain Controllers.

Read the series:

• Active Directory in Hyper-V environments, Part 1   
• Active Directory in Hyper-V environments, Part 2  
• Active Directory in Hyper-V environments, Part 3  
• Active Directory in Hyper-V environments, Part 4  
• Active Directory in Hyper-V environments, Part 5  
• Active Directory in Hyper-V environments, Part 6 

Meet me at the TechNet Deep Dive event

In four weeks time, Microsoft Netherlands will host an IT Pro event, named TechNet Deep Dive.

This event focuses primarily on datacenter management, security and identity management. The common theme is the New Efficiency. The event will be hosted on June 1, 2010 at Spant! in Bussum (in the Netherlands).

Speakers

For this event Microsoft flew in a couple of exiting speakers, including John Craddock, Nigel Cain and Kaj Wierda. Ronald Beekelaar and Tiander Turpijn will be joining them, forming an impressive line-up.

Ask the Experts

Since this type of events usually results in questions discussions, Microsoft has chosen to enhance this TechNet event with an ‘Ask the Experts’ booth. Looking at the sessions I think you might expect “Windows Server 2008 R2”, “Forefront” and “System Center”-branded booths at the event.

So, as Helmer concluded last TechNet event, the risk of meeting me up close and personal is high.

My booth of choice? The Windows Server 2008 R2 booth of course!

Related Posts

I'm doing a Technet Live session   
Speaking at the Dutch Launch Event  
Expert at the TechNet Live Netherlands event  

Further reading

Microsoft TechNet Deep Dive Website Dutch 
LinkedIn Events - Technet Deepdive - Learn form the Experts   
TechNetNL on Twitter    
TechNet Live : The Photo’s

Active Directory Federation Services 2.0 is here

Active Directory Federation Services (ADFS) 2.0, part of the federation platform codenamed ‘Geneva’, has been released to the web today!

ADFS helps IT enable users to collaborate across organizational boundaries and easily access applications on-premises and in the cloud, while maintaining application security. Through a claims-based infrastructure, IT can enable a single sign-on (SSO) experience for end-users to applications without requiring a separate account or password, whether applications are located in partner organizations or hosted in the cloud.

Further reading

ADFS 2.0 is in the house! 
Will ADFS 2.0 Boost Cloud Security? 
Microsoft's new directory-federation services finally ready to roll   
AD FS 2.0 TechNet Resource Center 
Claims based access forum - AD FS 2.0 and WIF 
AD FS 2.0 home page 
AD FS 2.0 is here!   
AD FS 2.0 Getting Started Guide   
AD FS 2.0 datasheet  
TechNet Webcast: Active Directory Federation Services (AD FS) 2.0 - Technical Overview   
A Guide to Claims-Based Identity and Access Control — Book Download   
Download Details - Windows Identity Foundation   
Download Details - Active Directory Federation Services 2.0

Early information on Tech·Ed Europe 2010

Tech·Ed is the annual Microsoft event, where IT Pros and developers meet with Microsoft representatives and Microsoft MVPs to learn and exchange information. Tech·Ed events are organized all over the world and Tech·Ed Europe is the event for IT Pros and developers from the European continent and the UK.

As a Tech·Ed veteran of sorts, I’m looking forward to another year of Tech·Ed Europe. So here’s the information that’s available so far:

If you want to receive notifications, join the Tech·Ed Europe mailing list for the latest news on upcoming Tech·Ed Europe events and special offers here.

I hope to see a lot of you in Berlin!

Related posts

Tech·Ed Europe 2009

• Tech∙Ed Europe 2009: Error 404 Wall not found  
• Tech∙Ed Europe 2009: Don’t get mad, get drunk    
• Tech∙Ed Europe 2009: Things to do in Berlin when you’re wasted   
• Tech∙Ed Europe 2009: We’re from Sweden! Where the bing are you from?  
• Tech∙Ed Europe 2009: Clubbing Barcelona style!    
• Tech∙Ed Europe 2009: Party like it’s 1989   
• This way to Tech∙Ed Europe 2009  
  

Tech·Ed EMEA 2008

• Tech∙Ed EMEA 2008 IT Pro Day 6 Recap 
• Tech∙Ed EMEA 2008 IT Pro Day 5 Recap 
• Tech∙Ed EMEA 2008 IT Pro Day 4 Recap 
• Tech∙Ed EMEA 2008 IT Pro Day 3 Recap 
• Tech∙Ed EMEA 2008 IT Pro Day 2 Recap     
• Tech∙Ed EMEA 2008 IT Pro Day 1 Recap 
• Tech∙Ed EMEA 2008 IT Pro Day 0 Recap 

Active Directory Domain Services Command Fu, Part 6

With Windows PowerShell Scripting being one of the requirements in the current Common Engineering Criteria (CEC), all Microsoft server products need to comply with having Windows PowerShell scripting support. While some Active Directory technologies have not yet adopted PowerShell (Active Directory Certificate Services, for example), Active Directory Domain Services has adopted this criteria wholeheartedly in Windows Server 2008 R2.

In post 6 in this Command Fu series, I think it’s appropriate to look at the management stuff that’s only available through PowerShell, when restricted to built-in Windows Management Tools.

In this blogpost: Creating and managing fine-grained password policies Enabling the Active Directory Recycle Bin Restoring objects from the Active Directory Recycle Bin Managing Managed Service Accounts

Part 1  Part 2  Part 3  Part 4  Part 5  Part 6

Creating and managing fine-grained password policies

PowerShell Cmdlets to use:

• Add-ADFineGrainedPasswordPolicySubject
• Get-ADFineGrainedPasswordPolicy
• Get-ADFineGrainedPasswordPolicySubject
• Get-ADUserResultantPasswordPolicy
• New-ADFineGrainedPasswordPolicy 
• Remove-ADFineGrainedPasswordPolicy
• Remove-ADFineGrainedPasswordPolicySubject
• Set-ADFineGrainedPasswordPolicy

Note:
The domain functional level will need to be Windows Server 2008, to be able to utilize this feature.

The Windows Server 2008 Domain Functional Level introduced a feature called Active Directory Password and Account Lockout Settings Objects (PSOs) and the concept of fine-grained password policies. These groups-oriented objects can be used to set (and if you’d like, enforce using precedence) password and account lockout settings to users and groups in Active Directory.

Note:
Before Windows Server 2008, the only scope on which these policies could be applied was the domain.

You cannot use the built-in Active Directory tools, like Active Directory Users and Computers (dsa.msc), to create and manage PSOs.

Instead, you can use the AdsiEdit MMC snap-in (adsiedit.msc), your favorite low-level Active Directory tool (ldp.exe, admod.exe) or specialized software, like SpecOps’ free Password Policy Basic (as advertised in every Microsoft Press book touching the subject), Cristoffer Andersson’s (Swedish Directory Services MVP) Fine Grained Password Policy tool or Joe Richards’ (US-based Directory Services MVP) PSOMgr.exe.

I think all of the above tools are awesome. But, I hear you asking, isn’t there a built-in command-line tool, that you can use to build one-liners to manage these Password and Account Lockout Settings Objects (PSOs)?

Yes, there is, in the form of a PowerShell cmdlet.

First, load the Active Directory module into your PowerShell, using the command

Import-Module Active Directory

Then put the New-ADFineGrainedPasswordPolicy cmdlet in action, as shown here on TechNet:

New-ADFineGrainedPasswordPolicy -Name "SalesUsersPSO" -Precedence 500 -ComplexityEnabled $true -Description "Sales Users Password Policy"-DisplayName "Sales Users PSO" -LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 10 -MaxPasswordAge "60.00:00:00" -MinPasswordAge "1.00:00:00" -MinPasswordLength 8 -PasswordHistoryCount 24 -ReversibleEncryptionEnabled $false

A long one-liner, I agree, but a one-liner nonetheless…

After creating the PSO, you can assign it to users and groups. Use the following command to make our good friend Jos Haarbos subject to the previously created Sales Users Password Policy:

Add-ADFineGrainedPasswordPolicySubject "Sales Users Password Policy" "Jos Haarbos"

Now, of course, with the possibility to assign Password and Account Lockout Policies to users and groups and users belonging to multiple groups, things tend to get messy fast. Therefore, a new cmdlet was created to get the Resultant Fine-grained Password Policy for a user:

Get-ADUserResultantPasswordPolicy "Jos Haarbos"

More information:

• PowerShell cmdlets (W2K8R2) for Fine-Grained Password Policy 
• Fine Grain Password Policy Tool 1.0 (2300.0) RTM 
• Windows Server 2008 - Fine Grained Password Policy Walkthrough 
• PSOMgr.exe | Command line tool to manage Fine Grain Password Policies 
• ActiveDir.org List Archive - Fine-grained password policy  using ldifde.exe 
• Windows Server 2008 - Fine-Grained Password Policies 
• Using Microsoft's New AD PowerShell Cmdlets   
• Active Directory Powershell Overview    

Enabling the Active Directory Recycle Bin

PowerShell Cmdlets to use:

• Set-ADForestMode
• Enable-ADOptionalFeature 

In part 3 of this series, I reflected on properly undeleting user objects from Active Directory in Windows Server 2003 with Service Pack 1 and onwards. However, in Windows Server 2008 R2, the Active Directory team has introduced a new feature, that makes this task even less of an effort. (You can read more on it in the next paragraph.)

This feature is called the Active Directory Recycle Bin. Enabling this feature requires three steps:

1. Upgrade all Domain Controllers in the forest to Windows Server 2008 R2
2. Raise the forest functional level to Windows Server 2008 R2
3. Enable the Active Directory Recycle Bin Optional feature.

The first step is pretty basic. At least… in an environment where all Domain Controllers are created equally (except for Global Catalog and Flexible Single Master Operations role placements) and aren’t misused for other purposes.

The second step is also pretty easy. While most Active Directory admins perform this task on a writable Domain Controller using Active Directory Domains and Trusts, (domain.msc), in Windows Server 2008 R2 you can use the Set-ADForestMode PowerShell cmdlet:

Import-Module Active Directory
Set-ADForestMode domain.tld  Windows2008R2Forest

The third step is also a simple PowerShell one-liner:

Enable-ADOptionalFeature –Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=domain,DC=tld' -Scope ForestOrConfigurationSet -Target 'domain.tld'

After execution of the command and proper replication to all Domain Controllers, you will have the Active Directory Recycle Bin enabled. All link-valued and non-link-valued attributes of deleted Active Directory objects are preserved and the objects are restorable in their entirety to the same consistent logical state that they were in immediately before deletion.

More information:

• Introducing Active Directory Recycle Bin  
• What's New in AD DS: Active Directory Recycle Bin  
• Active Directory Recycle Bin Step-by-Step Guide  
• How to raise forest / domain functional level using the command line 

Restoring objects from the Active Directory Recycle Bin

PowerShell Cmdlets to use:

• Get-ADObject
• Restore-ADObject 

As previously mentioned Windows Server 2008 R2 features the Active Directory Recycle Bin. After enabling it (on the command-line), I bet you’re wondering how to use it. Well… guess what… The easiest way to use it is through PowerShell.

That’s right! Again, the Active Directory released a kick-behind feature, without providing a graphical tool to manage it. As a command-line aficionado, by now, you should feel righteous about your move from the Graphical User Interface.

Of course the usual built-in suspects (AdsiEdit.msc, Ldp.exe) can be used to restore objects from the Active Directory Recycle Bin, but none of these tools is actually worthwhile when you need to restore … say …. twelve hundred user objects, since it would entail changing the specific attributes for each one of them.

Of course Joeware’s admod.exe, the PowerGUI Active Directory Recycle Bin PowerPack and ADRecycleBin.exe can be used, but none of these are available by default on a vanilla Windows Server 2008 R2 Domain Controller. Instead, you can pipe the Get-ADObject Cmdlet to the Restore-ADObject Cmdlet.

For instance, when you want to restore the accidentally deleted account for Jos Haarbos, you would use the following PowerShell one-liner after importing the Active Directory module:

Get-ADObject -Filter {displayName -eq "Jos Haarbos"}
-IncludeDeletedObjects | Restore-ADObject

Of course, not merely user objects can be restored. The biggest caveat here, however, is to remember you can only restore an object, when it’s parent object is present. When restoring a whole Organizational Unit (OU) with user objects, for instance, first restore the OU, then restore the user objects.

More information:

• Active Directory Recycle Bin 
• Active Directory Recycle Bin Step-by-Step Guide  
• How to: Recovering Deleted AD Objects in Windows Server 2008 R2  
• How do I use the Windows 2008 R2 Recycle Bin feature ? 
• Revive Deleted AD Objects with Active Directory Recycle Bin   
• Working with the Server 2008 R2 Active Directory Recycle Bin  

Managing Managed Service Accounts

PowerShell Cmdlets to use:

• New-ADServiceAccount
• Add-ADComputerServiceAccount
• Install-ADServiceAccount

Note:
The domain and forest will need to be prepared for Windows Server 2008 R2. When running pre-Windows Server 2008 R2 Domain Controllers, the functionality will work, except for automatic password and SPN management. It is therefore advised to use Windows Server 2008 R2-based Domain Controllers when utilizing this feature.

Note:
Both the machine on which you want to run the PowerShell commands and the machine where the service runs with the credentials of the managed service account, need to be running either Windows Server 2008 R2 or Windows 7, to be able to utilize this feature. When you use Windows 7 to manage managed service accounts you will need to install the Remote Server Administration Tools (RSAT).

Using Service Accounts with just enough privileges, is a best practice in Windows environments. While most services function perfectly with Local System, Network Service or Local Service accounts (and benefit from additional security in these scenarios too) privileges, other services require more isolation, more fine-grained rights assignment, outside communication, or communication between an application and its data.

For long, the built-in Administrator account was used for these purposes, but in a lot of environments this practice was (wisely) abandoned the first time the password for this account would have needed to be changed.

The Local System, Network Service and Local Service accounts have a couple of nice touches. For instance, these accounts change passwords often.

Another new feature in Windows Server 2008 R2 Active Directory is the Managed Service Account. This new object type, derived from the computer account object, offers a big benefit: just like with a computer account and the typical local system accounts, the managed service account will automatically change it password regularly. IT can also update its Service Principle Name (SPN) automatically.

From a security point of view, this means, in a worst case scenario, a sniffed (and decoded) password(hash) can only be used for a limited amount of time. It also means that when the account is only given the barely minimum privileges, an attacker cannot exploit a vulnerability in the service, beyond the service itself.

Note:
Probably because of this security concern, a managed service account can only be assigned to one host at the time.

From a management point of view, it means you can create automatically changing service accounts per service per host. After renaming the host, the service will start like it did before.

The command to create a Managed Service Account after enabling PowerShell Active Directory Management (using Import-module Active Directory) would look something like:

New-ADServiceAccount -Name MSA-Host1 -Path "CN=Managed Service Accounts,DC=domain,DC=tld"

Note:
While creating a Managed Service Account is also possible using Active Directory Users and Computers (ds.msc), this is not the ideal way to create these accounts.

Then, to assign the Managed Service Account to a host, use the following command:

Add-ADComputerServiceAccount -Identity Host1
-ServiceAccount MSA-Host1

As a last step, install the Managed Service Account on the host, that hosts the service, in this case Host1:

Import-module Active Directory
Install-ADServiceAccount -Identity MSA-Host1

After this third step you can configure the service to run using the managed service account.

More information:

• Create Managed Service Accounts with PowerShell. Do not create managed service accounts with Active Directory Users and Computers.  
• What's New in Service Accounts  
• Controlling Windows Services and Service Accounts  
• Managed Service Accounts  
• Server 2008 R2 Managed Service Account Bug