Updated DirSync can now be deployed on a Domain Controller.

Microsoft recently released a new version of Windows Azure Active Directory Sync, better known as DirSync. As the information on the Version Release History page of the tool depicts, this new build allows you to deploy DirSync on a Domain Controller.

Along with this new ability, this new version (6553.0002) also includes some fixes:

  • Fix to address Sync Engine memory leak
  • Fix to address "staging-error" during full import from Azure Active Directory
  • Fix to handle Read-Only Domain Controllers in Password Sync

The latest version can be downloaded from the following page:

Have fun!

Blog Office 365

Active Directory Requirements for Exchange Server 2013 Preview

Disclaimer:

All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

With Exchange Server 2013 Preview, it seems that Microsoft is “pushing” customers towards using Server 2008 or later. Not that I think that that is a bad thing, in the contrary! However, I still see customers that have Windows Server 2003 deployed and are using them as main Domain Controllers/Global Catalogs.

As per documentation, it seems no longer supported for Exchange Server 2013 Preview. You need at least one DC/GC running Windows Server 2008 or higher.

Although the Schema Master can still be Windows Server 2003, it seems logical to me that you’d rather standardize entirely on Server 2008, perhaps shortly even on Server 2012.

Below is an overview of the requirements for Active Directory:

Active Directory Forest Level: at least Windows Server 2003 or higher.

Schema Master: required for updating the AD schema for Exchange Server 2013 Preview

  • Windows Server 2012
  • Windows Server 2008 R2 Standard or Enterprise
  • Windows Server 2008 Standard or Enterprise (32-bit or 64-bit)
  • Windows Server 2003 Standard Edition with Service Pack 2 (SP2) or later (32-bit or 64-bit)
  • Windows Server 2003 Enterprise Edition with SP2 or later (32-bit or 64-bit)

Global Catalog: each AD site that has a Exchange Server 2013 Preview installed, requires at least one server running:

  • Windows Server 2012
  • Windows Server 2008 R2 Standard or Enterprise
  • Windows Server 2008 R2 Datacenter RTM or later
  • Windows Server 2008 Standard or Enterprise (32-bit or 64-bit)
  • Windows Server 2008 Datacenter RTM or later

Domain Controller: each AD site that has an Exchange Server 2013 Preview installed, requires at least one server running:

  • Windows Server 2012
  • Windows Server 2008 R2 Standard or Enterprise SP1 or later
  • Windows Server 2008 R2 Datacenter RTM or later
  • Windows Server 2008 Standard or Enterprise SP1 or later (32-bit or 64-bit)
  • Windows Server 2008 Datacenter RTM or later
Blog Exchange 2013

Installing Exchange Server 2013 Preview Prerequisites

Disclaimer:

All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

In this article, we will have a first look at the different system prerequisites for installing Exchange Server 2013.

Supported Platforms

You can install Exchange Server 2013 either on Windows Server 2008 R2 or Windows Server 2012. Just as with Exchange Server 2010, you will need the enterprise edition of Windows Server 2008 R2 if you are going to deploy a Database Availability Group (DAG).

As recently announced, Windows Server 2012 does not include an Enterprise Edition anymore. The Standard Edition now also covers all product features. The number of licenses you need depends on the number of physical processors your system will have.

For a nice and clear overview of the licensing changes, please have a look at Aidan Finn’s blog post.

Preparing Active Directory

On the computer you are going to use to prepare Active Directory, you need at least the Remote Server Administration Tools for Active Directory installed. To install the tools, open up PowerShell and type in the following commands:

Import-Module ServerManager

Add-WindowsFeature RSAT-ADDS (if you’re running WS2008R2)

Install-WindowsFeature RSAT-ADDS (if you’re running WS2012)

You will also need the Microsoft .NET Framework 4.5 and Windows Management Framework 3.0. They are both already included on a system running Windows Server 2012.

Note  make sure that you have appropriate permissions to execute the tasks listed below. Permissions include membership of the Schema Admins and Enterprise Admins group.

Just as with Exchange Server 2010 – the following tasks need to be execute to prepare the Active Directory:

  • Update Schema
  • Prepare AD
  • Prepare Domains
    To update the schema, launch a PowerShell console and type in the following:

./setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

Note the use of “setup.exe”. Setup.com which was used before has been deprecated. There is also a new switch “/IAcceptExchangeServerLicenseTerms”. It will prevent the mandatory time-out which displays the warning that by waiting you agree with the license terms.

    Next, you’re up for preparing the AD:

./setup.exe /PrepareAD /ON:<exchange organization name>

This command will prepare Active Directory and amongst others configure the appropriate permissions. This includes the creation of the Microsoft Exchange Security Groups (if they do not exist yet).

Lastly, you need to prepare the domain(s). As part of this task, setup will create/update the Microsoft Exchange System Objects container, update the objectVersion attribute and create a domain local group in the targeted domain called “Exchange Install Domain Servers”.

System Prerequisites for Mailbox Server or Mailbox/Client Access Server (combined):

First, on the computer you are going to install Exchange Server 2013, run the following commands (PowerShell) to install the required Roles and Features:

For Windows Server 2012:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

For Windows Server 2008 R2:

Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI

After you installed the operating system roles and features, you should install the following items:

Windows Server 2008 R2 Windows Server 2012
Microsoft .NET Framework 4.5 Microsoft Office 2010 Filter Pack 64 bit (Mailbox Server Role)
Windows Management Framework 3.0 Microsoft Office 2010 Filter Pack SP1 64 bit (Mailbox Server Role)
Microsoft Unified Communications Managed API 4.0n Core Runtime 64bit Microsoft Unified Communications Managed API 4.0n Core Runtime 64bit
Microsoft Office 2010 Filter Pack 64 bit (Mailbox Server Role)
Microsoft Office 2010 Filter Pack SP1 64 bit (Mailbox Server Role)
Microsoft KB974405 (Windows Identity Foundation)
Microsoft KB2619234
Microsoft KB2533623

Once you installed the required prerequisites, execute the following steps:

  • Uninstall Microsoft Visual C++ 11 Beta Redistributable (x64)
    • Open Control Panel > Programs and Features.
    • Select Visual C++ 11 Beta Redistributable (x64) – 11.0.50531 and then click Uninstall.
    • In Microsoft Visual C++ 11 Beta setup, click Uninstall.
    • When Microsoft Visual C++ 11 Beta is uninstalled, click Close.

If you are running Windows Server 2008 R2, you should also execute the following step. Please note that you should execute this step afterhaving uninstalled Microsoft Visual C++ 11 Beta Redistributable (x64) and before you install Exchange Server 2013:

  • Register ASP.Net with .NET Framework 4.5 in IIS.

Open Command Prompt and type in the following commands:

%SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir -enable

IISReset

System Prerequisites Client Access Server only:

First, on the computer you are going to install Exchange Server 2013, run the following commands (PowerShell) to install the required Roles and Features:

For Windows Server 2012:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

For Windows Server 2008 R2:

Import-Module ServerManager

Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI

After you installed the operating system roles and features, you should install the following items:

Windows Server 2008 R2 Windows Server 2012
Microsoft .NET Framework 4.5 Microsoft Unified Communications Managed API 4.0n Core Runtime 64bit
Windows Management Framework 3.0
Microsoft Unified Communications Managed API 4.0n Core Runtime 64bit
Microsoft KB974405 (Windows Identity Foundation)
Microsoft KB2619234
Microsoft KB2533623

Once you installed the required prerequisites, execute the following steps:

  • Uninstall Microsoft Visual C++ 11 Beta Redistributable (x64)
    • Open Control Panel > Programs and Features.
    • Select Visual C++ 11 Beta Redistributable (x64) – 11.0.50531 and then click Uninstall.
    • In Microsoft Visual C++ 11 Beta setup, click Uninstall.
    • When Microsoft Visual C++ 11 Beta is uninstalled, click Close.

If you are running Windows Server 2012, you should manually create a firewall rule. This rule will allow the Mailbox Server(s) to access the Client Access Servers’ registry:

    • Open Control Panel > Windows Firewall.
    • Click Advanced Settings.
    • In Windows Firewall with Advanced Security, click Inbound Rules and then click New Rule.
    • Select Port and then click Next.
    • Select TCP, and in Specify local ports, type 139. Click Next.
    • Select Allow the connection and then click Next.
    • Make sure Domain, Private, and Public are selected and then click Next.
    • Enter a name and description for the new rule and then click Finish.

If you are running Windows Server 2008 R2, you should also execute the following step. Please note that you should execute this step afterhaving uninstalled Microsoft Visual C++ 11 Beta Redistributable (x64) and before you install Exchange Server 2013:

  • Register ASP.Net with .NET Framework 4.5 in IIS.

Open Command Prompt and type in the following commands:

%SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir -enable

IISReset

Once you’ve completed the steps above, you are ready for deploying Exchange Server 2013 Preview!

Exchange 2013 How-To's

Sessions I would attend @ TechEd Europe (26-29 june, Amsterdam)

TechEd is coming back to Europe and this time it’s striking down in Amsterdam from the 26th to the 29th of June. TechEd is, in my opinion of course, a one of a kind conference packed with lots and lots of great sessions about various topics. If you have the opportunity to attend the conference: don’t hesitate!

A few days ago, the first sessions were announced so I went and had a peak at what was coming our way. The conference, usually divided into multiple “tracks”, allows you to easily identify your area of interest and pick your sessions accordingly. Because of my background (and strong personal interest), I mainly focus on the following tracks:

What you will notice is that, although I spend most of my time with products like Exchange, most of the sessions I picked are from the Security & Identity track. Why is that? Well, Exchange has been around for quite some time now. This does not mean that I know the product inside out, but a lot of things have already been said and by nature I rather tend to look into the future than looking back. This is also why I would focus more on new(er) products and technologies. At this time, Windows Server 8 (and therefore also Active Directory) fits that description perfectly, hence the choice for session that mostly talk about it and it’s new features.

For one, if it were possible, I would attend all of them. But at conferences like TechEd, it’s all about choices. The list below depicts the sessions that I would attend. Please keep in mind that these are my personal choices and it does not mean that other sessions are less worth attending!

Exchange & Lync

  • Best Practices for Virtualizing Microsoft Exchange Server 2010
  • Deep Dive: Coexistence between Microsoft Office 365 and Microsoft Exchange Server 2010
  • Microsoft Exchange Server 2010 High Availability Deep Dive
  • Microsoft Exchange Server 2010: Troubleshooting Performance Issues

Office, Office 365 & SharePoint

  • Security Design with Claims Based Authentication

Security & Identity

  • Active Directory Virtualization Safeguards and Domain Controller Cloning with Windows Server “8”
  • How to (un)Destroy Your Active Directory: Reloaded
  • Managing and Extending Active Directory Federation Services
  • Planning, Designing, and Deploying a Highly Available AD RMS Infrastructure
  • Windows Server “8” Dynamic Access Control Best Practices and Case Study Deployments in Microsoft IT
  • Windows Server “8” Dynamic Access Control Deep Dive for Active Directory and Central Authorization Policies
  • Windows Server 8 Dynamic Access Control Overview

Events

Working with SIDs in PowerShell

Recently, I was creating a PowerShell script in which it turned out that I needed to use SIDs to uniquely identify an object. There might be other ways to uniquely identify an object/account but the SID just seemed easiest.

One of the things I wanted to achieve is to know what object belonged to a specific SID and the other way around. Since I didn’t know if the SID belonged to a user or to a group, I couldn’t rely on the Get-ADUser cmdlet and filter based on the SID:

Get-ADUser –Filter {SID –eq <sid>}

If the SID would belong to a group, the cmdlet above wouldn’t return anything. I could use an if-else statement, but that still would not guarantee a correct result. Furthermore, every time I fire the script I risk that the script has to go through multiple loops which would probably negatively influence the script’s performance.

Luckily, PowerShell has some built-in features that allow you to “convert” an SID into an account (or the other way around). Think about it for a minute: since you already have the SID, you know what account it belongs to. You just need to go and fetch it. There’s no need to loop through all objects and see if a match can be found…

How does it work then? First, we need to create a new object either from the SID class or from the NTAccount class. Afterwards, we fetch the account name where the SID belongs to using the Translate method:

$object = New-Object System.Security.Principal.SecurityIdentifier (“S-1-5-21-1464570058-3711975594-539085127-1210”)
$result = $object.Translate([System.Security.Principal.NTAccount])
$result.Value

This is how it looks like if we run it from PowerShell:image

We can also make it work the other way around (from account name to SID):

$object = New-Object System.Security.Principal.NTAccount(“exblog”,”mvanhorenbeeck”)
$result = $object.Translate([System.Security.Principal.SecurityIdentifier])
$result.Value

image

Note: this approach unfortunately does not work for computer accounts. It can only be used for users or groups.

Blog

Windows 8: support for snapshotting/cloning a DC is coming…

Hi,

it’s been a while that I was able to write a blog post (busy, busy, busy). But since I’ve got a little spare time left, I couldn’t resist to talk to you about a feature that I’m actually very excited about.

As most of you know by now, Windows 8 will bring a lot of (good) changes to us. Not only will we be getting Hyper-V 3.0 but also some other enhancements under the hood.

I previously blogged about some changes in Windows 8 Active Directory and today I would like to add something to that list: support for cloning and snapshotting a Domain Controller.

USN Rollback

Currently, snapshotting a virtualized Domain Controller is not possible because reverting to a snapshot you’ve taken earlier would cause a so-called USN rollback.

If you want more information on what that is, take a look here: USN and USN Rollback

Generation ID

The ability to support both snapshotting/cloning isn’t an accomplishment solely from Windows 8. It also needs a new functionality from the Hypervisor that it’s running on: Generation ID. Unfortunately, there is not much (public) information out there on this new functionality…

The Generation ID is an attribute that is generated by the Hypervisor to indicate the version of the VM that is running. If you apply an older snapshot, that ID needs to get updated/changed as well. Windows 8 will leverage this functionality and “copy” the value of the Generation ID into a new AD-attribute: ms-ds-Generation-ID. This value will be stored locally on the server. Before carrying out any transactions (e.g. due to replication), the DC will check the value stored in the VM (ms-ds-Generation-ID) with the value that Hyper-V has stored. If the value is the same, the transactions is carried out. However, if the value is different, the DC assumes it has been reset to an older state and will not carry out that transaction. Instead it will change it’s Invocation ID (more info in the “USN and USN Rollback”-article); notifying other DCs that it is on a previous version. What happens next is quite similar as to what happens if you do a restore of AD from a backup.

Currently only Hyper-V supports the Generation ID attribute, but Microsoft is working on getting this available throughout other hypervisors (like ESX, XenServer,…) as well.

Note: I found an interesting article on the internet (in German) that states if a difference in the Generation ID is detected, the DC will also take some other actions to make sure that it will not service any client requests until it is back up-to-date. However; I wasn’t able to verify that information. Nonetheless, what is described there seems quite logical to me and I don’t have any reasons to believe the information would be wrong:

http://www.faq-o-matic.net/2011/12/05/ad-in-windows-server-8-was-wahrscheinlich-kommt/

See you later!

Michael

Blog

Configuring Windows 8 Active Directory Domain Services (ADDS)

Hi there!

As you might know, Windows 8 will bring us tons of new features and improvements, some of which have been long awaited. Over the upcoming weeks, I’ll try to produce some blog posts about these changes and improvements with regards to Active Directory.

Note: the information below is coming from an early version of Windows 8 (developer preview) and there might be small (or bigger) changes in the final version of the product.

Goodbye ‘dcpromo’…

In this first article, I wanted to talk about the configuration of Active Directory. Ever since AD was introduced, IT Pro’s were drilled to use the “dcpromo” command line tool to create a new DC (whether this was to add or remove a DC).

Well, the “era” of this command seems to come to an end with Windows 8 (at least according to what I’ve noticed so far) :

image

As we will see later, and alternative to the tool is now provided by PowerShell.

Configuring ADDS

Entirely according to what I’ve expected, ADDS can be configured from within the redesigned server manager. As soon as you’ve added the ADDS-role, a new option becomes available:

image

image

ADDS Configuration Wizard

Clicking “Promote this server to a domain controller”, will launch the Active Directory Domain Services Configuration Wizard (formerly known as “dcpromo”).

In this scenario, I’ll be adding a domain controller to an existing domain.

On the first page of the wizard, choose your deployment type and enter the necessary details (no surprises here):

image

Select the options for your (new) Domain Controller and choose a Recovery Mode password (don’t loose it!):

image

The setup will now ask to create a DNS delegation. Again: choose the appropriate settings and click Next:

image

Choose where to store AD-related files:

image

The next page contains a nice ‘surprise’: as is the case with Exchange 2010, the wizard allows you to copy-paste the PowerShell-code it is using to execute the task with the selected options. This allows you to easily create your own script(s) from it:

image

image

As you can see, the Install-ADDSDomainController cmdlet is used. This cmdlet is part of the ADDS Deployment Module for PowerShell which has been introduced in Windows Server 8. More information about these cmdlets can be found in one of my previous articles.

Now that we’ve completed the wizard, it will start configuring ADDS. But before doing so, the wizard will run a quick check to see if all prerequisites have been met:

image

You have the option to automatically reboot the server after completion (as was the case with the ‘old’ dcpromo.exe)

image

A final word

In my opinion, these changes – although they might seem small at first – can (and probably will) have an impact on how we deploy domain controllers. I remember that automating the installation (promotion) of a DC could be a real pain in the butt. However, thanks to the new deployment cmdlets and a easy-to-use wizard which is more complete than before, deploying a new or additional DC’s will become a piece of cake.

Does this mean that you should be deploying DC’s just because you can? Of course not. Mind that the ease of deployment might open up some doors to advanced automated deployment in a private cloud, yet deploying a Domain Controller should always be well overthought and –considered.

Until later!

Michael

Blog