The things that are better left unspoken

Server Manager in Windows Server 2008 R2, Part 3

2010-07-04T19:19:02Z

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…

Server Manager in Windows Server 2008 R2, Part 2

2010-07-04T10:09:58Z

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)

Module	Server Role / Feature
ActiveDirectory	Active Directory Domain Services
ADRMS **	Active Directory Rights Management Services
AppLocker **	AppLocker
BestPractices **	Best Practices Analyzer
BitsTransfer *	Background Intelligent Transfer Service
FailoverClusters	Failover Clustering
GroupPolicy	Group Policy Management
NetworkLoadbalancingClusters	Network Load Balancing
PSDiagnostics *	PowerShell Diagnostics
RemoteDesktopServices	Remote Desktop Services
ServerManager **	Server Manager
TroubleshootingPack **	Windows Troubleshooting Wizards
Internet Information Services	WebAdministration

* 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:

Add-WindowsFeature
Get-WindowsFeature
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.

Server Manager in Windows Server 2008 R2, Part 1

2010-07-02T23:41:00Z

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!

Four in a row

2010-06-25T12:49:59Z

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!

2010-06-19T14:53:00Z

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.

Server Core Anytime Upgrades

2010-06-08T07:17:08Z

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:

Source Windows Server 2008 R2 SKU	Target Windows Server 2008 R2 SKU
Windows Server 2008 R2 Standard x64 "ServerStandard"	Windows Server 2008 R2 Enterprise x64 "ServerEnterprise" Windows Server 2008 R2 Datacenter x64 "ServerDatacenter"
Windows Server 2008 R2 Enterprise x64 "ServerEnteprise"	Windows Server 2008 R2 Datacenter x64 "ServerDatacenter"

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.

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

Speaking engagements for June

2010-05-29T06:38:00Z

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

2010-05-26T05:40:00Z

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

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:

adprep.exe	Use adprep.exe to prepare your Active Directory environment for Windows Server 2008 R2 on 64bit (x64) Domain Controllers.
adprep32.exe	Use adprep.exe to prepare your Active Directory environment for Windows Server 2008 R2 on 32bit (x86) Domain Controllers.

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

Command	Domain Controller
adprep.exe /forestprep adprep32.exe /forestprep	Schema Master
adprep.exe /domainprep adprep32.exe /domainprep	Infrastructure Master
adprep.exe /domainprep /gpprep adprep32.exe /domainprep /gpprep	Infrastructure Master
adprep.exe /rodcprep * adprep32.exe /rodcprep	Domain Naming Master

* 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:

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.
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:

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..
Open Active Directory Domains and Trusts.
In the console tree, right-click the domain for which you want to raise functionality, and then click Raise Domain Functional Level.
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:

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.
Open Active Directory Domains and Trusts.
In the console tree, right-click Active Directory Domains and Trusts, and then click Raise Forest Functional Level.
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.

Logon to a domain controller that has Windows Server 2008 R2 installed.
Open Server Manager.
In the console tree of Server Manager, expand the Roles node, and then select the Active Directory Domain Services role.
Scroll down to the Best Practice Analyzer section.
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!

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

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

2010-05-10T00:15:49Z

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

NT 4.0 Compatible Encryption

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:

Log on to a Windows Server 2008-based or Windows Server 2008 R2-based Domain Controller.
Click Start, click Run, type gpmc.msc, and then click OK.
In the Group Policy Management console, expand Forest: DomainName, expand DomainName, expand Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.
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.
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.

Going 64 (bit)

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.

Getting acquainted with the Command-line

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:

Limited ways to migrate to 2008 R2

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.

Deploying Server Core Domain Controllers

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.

Virtualizing Domain Controllers

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:

Meet me at the TechNet Deep Dive event

2010-05-06T04:14:00Z

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!

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

Active Directory Federation Services 2.0 is here

2010-05-05T10:48:30Z

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.

Early information on Tech·Ed Europe 2010

2010-04-27T23:22:18Z

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:

Event title	Microsoft Tech·Ed Europe 2010
Dates	November 8, 2010 – November 12, 2010
Venue	Messe Berlin, Berlin (Germany)
Registration opening	July 5, 2010
Twitter hashtag	#tee10

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!

Tech·Ed Europe 2009

Tech·Ed EMEA 2008

Active Directory Domain Services Command Fu, Part 6

2010-04-27T20:37:32Z

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:

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:

Upgrade all Domain Controllers in the forest to Windows Server 2008 R2
Raise the forest functional level to Windows Server 2008 R2
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:

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:

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:

Office 2010: Ready, Set, Go?

2010-04-27T11:52:27Z

Microsoft Office 2010 and Microsoft Sharepoint 2010 are Microsoft’s latest and greatest Information Worker flagship products. Since it’s available and downloadable for Microsoft Partners (and everyone else with a MSDN or TechNet subscription), one of my first thoughts was to begin asking questions.

While trying to answer the question “Are we ready for Office 2010?” , already a couple of roadblocks emerged for large environments.

This process reminded me about the Windows 7 deployment process, so let’s make a checklist and see whether we’re good to go…

A business-oriented Office 2010 deployment plan

Office is more than just Word, Excel, PowerPoint, Outlook and Access. While these applications certainly account for most of the popularity and use cases of Microsoft Office, other Office applications can also make your business flow more easily.

Infopath, OneNote, Sharepoint Workspace (formerly known as Groove), Visio and Project are front-end Office applications that address specific pain points and challenges.

Sharepoint 2010 and Exchange 2010 are back-end Office applications and provide server-based centralized storage, versioning, workflow management and web-based client capabilities.

Make your plan with business leaders, but also include some representative end users. Put Kotter’s eight step change management model to good use!

A technology-oriented Office 2010 deployment plan

You should also have a basic understanding of the technical choices you’ll want to make in your Office 2010 deployment.

One good tip I received from Microsoft is to deploy Office 2010 x86 by default. While Office 2010 x64 sounds fantastic, you should avoid it. It’s only useful when using Office 2010 Power Pivot with millions of rows and columns. Now, how many people do you know who work with that kind of files?

Another important choice is whether you want to deploy Office in a big bang or gradually throughout the organization.

From an Active Directory point of view you’ll want the Microsoft Office 2010 Administrative Templates for the deployed architecture.

An Office 2010 compatible volume activation infrastructure

You can use Windows 7 and Windows Server 2008 R2 as Key Management Server (KMS) host to activate Office 2010 installation in a large environment. alternatively you can use Multiple Activation Keys (MAKs), but this is not a really scalable solution. You will need to install the Microsoft Office 2010 KMS Host License Pack to activate Office 2010 installations.

An Office 2010 compatible application delivery solution

Multiple methods for deploying Office have been used in the last couple of years:

Software Installation through Group Policy (msi-based),

Microsoft Application Virtualization (App-V),

Microsoft Enterprise Desktop Virtualization (Med-V),

Server-based Computing (Office through Terminal Services) and

command-line installation through BDD/MDT with an Office Installation Point.

How you will be deploying Office 2010 largely depends on the way a previous version of Office is deployed right now. When the deployment method suffices, reuse it. When you want to tweak it, now’s the moment! Here’s an overview of the Office 2010 Deployment Options.

Since deployment hasn’t changed much between Office 2007 and Office 2010, you won’t find many problems on your path when you already deployed Office 2007.

Office 2010 compatible business applications (and support)

Users with Windows and Office don’t make most companies run. Line of Business (LoB) applications are needed for business purposes most of the time. They’d better be 100% compatible too.

Whether you’re using an obscure Groupware solution with an even more obscure Outlook client plug-in, or an old version of Microsoft CRM, the integration between these components should be flawless for the business to continue. Deploying Office x86 instead of Office x64 will get you a long way in terms of compatibility.

Inventory, Communication with the vendor and testing should be completed. Testing is done in a testing environment. You do have a testing environment, right? Right. You might not have a production environment, though…

An Office 2010 compatible search infrastructure

With Windows Vista and Windows 7 on desktops Microsoft’s emphasis on search is clear to your colleagues. However, Microsoft Office 2010 files need to be searchable for content and aren’t by default on machines not running Office 2010 (for instance File Servers). Installing the Office 2010 Filter Pack on these machines solves this challenge.

Access to Office 2010 files when Office 2010 is not around

While Office Web Apps solve a lot of problems with its functionality to create and manipulate Office files in a web environment, in some cases this functionality isn’t worth anything. For these situations you can resort to the Office viewers.

Office 2010 compatible Office Business Applications (OBAs)

Microsoft Office Word, Excel and Microsoft Office Access are great tools for end-users to build productivity tools. But with newer Office versions, some programming functionality has drastically changed. The business applications built in these applications (Office Business Applications, or OBAs) should also be inventoried and addressed.

The Office Migration Planning and Managee (OMDM) is a perfect tool to scan the file servers and client-pc’s for Office documents and possible problems with them, store the information in a centralized database and report on these documents and potential problems. A couple of tools are also part of this tool to assist you in addressing the problems.

Sounds like a great tool and its currently part of the Microsoft Proof of Concept (PoC) Jumpstart Kit 1.0 for Windows 7. A must-have toolkit for any Microsoft Optimized Desktop-related migration project. Don’t spend time going at it alone… use the right tools. (not everything is a nail)

Office 2010 End User Training

The most productive Office version ever… Sure, with End User Training. Without end users knowing the specifics of the Office 2010 applications, you cannot expect them to be fully productive. Then again, will you would probably come up with some good business benefits in your business deployment plan, users with the right tools will come up with even greater benefits.

Office 2010 certification

Of course your boss wants you to be a good systems administrator. Microsoft offers the Microsoft Office Specialist (MOS) certification for Office 2007 and will continue on the MOs path. Information on the MOS certification for Office 2010 and the corresponding exams is still meager at this point.

Windows 7 Migration Checklist
Office 2010 RTM and available on Technet

Active Directory Domain Services Command Fu, Part 5

2010-04-26T12:28:18Z

As some systems administrators have already found out, on Microsoft Windows Servers some tasks cannot be performed using the Graphical User Interface (GUI). Although multiple vendors have released graphical tools to make these tasks ~~even more tedious~~ easier for the typical click-on-through Windows Admin, these tasks can easily be performed using the built-in command tools.

As you might have noticed already, the more complex features of Active Directory Domain Services are hidden from plain sight and into the command-line. In Windows Server 2008 R2, a couple of new command-line gems were added by the Active Directory team. Let’s check them out!

Note:
Other new features are also command-line only, but not in the traditional sense. Find out more in part 6 of this series!

In this blogpost:

Offline Domain Join
Creating IFM media with SYSVOLs

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

Offline Domain Join

Command to use

djoin.exe

When you want to join a Windows computer to an Active Directory domain, in the past, you would have needed a direct connection with a Domain Controller.

Windows Server 2008 R2 and Windows 7 change that game. With the feature called Offline Domain Join, you can now join a (pre-staged) computer to an Active Directory domain, without a dedicated connection. The Domain Controller no longer needs to ‘see’ the client and the client does not need to meet the Domain Controller.

The Offline Domain Join feature is achieved using a blob. The blob contains all the information a client (or member-server) needs to join the domain. You create the blob on the Domain Controller using the djoin.exe command.

You can use the contents of the blob on the client or soon-to-be member server using the djoin.exe command or by injecting the blob into the system using an answer file in combination with Windows Setup or the Windows Mini Setup, through the System Preparation Tool (sysprep.exe)

To create an Offline Domain Join blob on the Domain Controller, run the following command:

djoin.exe /PROVISION /DOMAIN Domain.tld /MACHINE ClientName /SAVEFILE D:\OfflineProvisioning\ClientName.txt

You can then use the blob you created on a Windows 7 or Windows Server 2008 R2-based Windows installation to join it to the domain in an offline fashion, using the following command:

djoin.exe /REQUESTODJ /LOADFILE C:\Djoin\clientname.txt /WINDOWSPATH C:\Windows

After the client successfully works through the command, the would-be client reboots as a member of the Active Directory domain. On first contact between the client and the Active Directory domain, the client would reset its Computer Account password.

More information:

Creating IFM media with SYSVOLs

Command to use:

ntdsutil.exe

dcpromo.exe

Note:
You will need a Windows Server 2008 R2 Domain Controller to create “Install from Media” (IFM) media with System Volumes (SYSVOLs) included. To use the IFM media, the additional Domain Controller must also be running Windows Server 2008 R2.

Install from Media (IFM) is an additional Active Directory Domain Controller promotion method, where you reduce the replication traffic that is initiated during the promotion. You perform an “Install from IFM” using IFM Media. You create these media with ntdsutil.exe.

In organizations with large System Volumes (SYSVOLs) the initial replication during the installation of an additional domain controller using IFM, would still take long and require significant bandwidth and data usage. Starting from Windows Server 2008 R2, you can also include the System Volume in IFM media. This will further reduce (not completely eliminate though) traffic.

When creating IFM media, take note of the following:

IFM media must be created on a Domain Controller in the same domain as you want to promote the additional Domain Controller;
When you want to install a Global Catalog server from IFM, create IFM media on a Global Catalog server;
When you want to make the additional Domain Controller a DNS Server, create IFM media on a Domain Controller with a DNS Server installed;
You can use a 32-bit domain controller to generate installation media for a 64-bit domain controller; the reverse is also true.

To create IFM media in the IFM folder with the System Volume included, in order to create a writeable additional Domain Controller, run the following command:

ntdsutil.exe "act inst NTDS" ifm "Create Sysvol Full C:\IFM” q q

To create IFM media to create an additional Read-only Domain Controller, run the following command:

ntdsutil.exe "act inst NTDS" ifm "Create Sysvol RODC C:\IFM" q q

Then, after you copy the contents of the target IFM folder to the additional domain controller, to promote it, use dcpromo.exe and use the advanced mode installation. When you’re really cool, you’d use an unattend file or script to dcpromo.exe command with the ReplicationSourcePath option.

More information:

The things that are better left unspoken

Server Manager in Windows Server 2008 R2, Part 3

About Best Practices Analyzers

Best Practices Analyzers (BPAs)

Part of Server Manager

Extended to TechNet

Updated through Windows Update

Also available in PowerShell

Concluding

Further reading

Server Manager in Windows Server 2008 R2, Part 2

PowerShell

PowerShell Modules

PowerShell Remoting

Concluding

Further reading

Server Manager in Windows Server 2008 R2, Part 1

Configuration items

Links and Wizards

Server Manager Remoting

Concluding

Further reading

Four in a row

ADMT 3.2 Now Available!

Downloads

Further reading

Server Core Anytime Upgrades

Windows Anytime Upgrade FAQ

Windows Anytime Upgrade paths

Windows Anytime Upgrade commands

Windows Anytime Upgrade Benefits

Concluding

Related posts

Further reading

Speaking engagements for June

TechNet Deep Dive

Experts Live

VirtualStudy Conference

NGN Live TV

Transitioning your Active Directory to Windows Server 2008 R2

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 FSMOs and GCs

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

Related posts

Further reading

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

NT 4.0 Compatible Encryption

Going 64 (bit)

Getting acquainted with the Command-line

Limited ways to migrate to 2008 R2

Deploying Server Core Domain Controllers

Virtualizing Domain Controllers

Meet me at the TechNet Deep Dive event

Speakers

Ask the Experts

Related Posts

Further reading

Active Directory Federation Services 2.0 is here

Further reading

Early information on Tech·Ed Europe 2010

Related posts

Tech·Ed Europe 2009

Tech·Ed EMEA 2008

Active Directory Domain Services Command Fu, Part 6

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