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

Windows 8 Active Directory: New Deployment PowerShell Cmdlets

In my previous blog post, I talked about some of the new cmdlets that were introduced in Windows Server 8 for managing Active Directory. Today, we’ll focus on cmdlets that were added for deploying and configuring Active Directory.

Previously, if you wanted to configure AD DS, you had to use the DCPROMO.exe utility. However, in Windows Server 8 this tool has been deprecated and replaced by a brand new cmdlet: Install-ADDSDomainController.

The cmdlets for deploying ADDS have been grouped into a separate module: ADDSDeployment. As a result, you can run the following command to retrieve a list of all available cmdlets within the module:

Get-Command –Module ADDSDeployment

Get-ActiveDirectoryDomainNames                                                
Get-ActiveDirectorySiteNames                                                  
Invoke-ADDSCanContactOtherDCsinDomain                                         
Invoke-ADDSDoesDCHostOperationMasterRole                                      
Invoke-ADDSDoesDNSDelegationForThisMachineExistInParentZone                   
Invoke-ADDSDoesDomainNamingContextExist                                       
Invoke-ADDSGetAllowedRodcReplicationAccounts                                  
Invoke-ADDSGetApplicationPartitionsInForest                                   
Invoke-ADDSGetDatabaseFacts                                                   
Invoke-ADDSGetDefaultDNSOption                                                
Invoke-ADDSGetDefaultSiteName                                                 
Invoke-ADDSGetDeniedRodcReplicationAccounts                                   
Invoke-ADDSGetDnsDelegationOptions                                            
Invoke-ADDSGetDomainControllersInDomain                                       
Invoke-ADDSGetExistingDCAccountInfo                                           
Invoke-ADDSGetForestFunctionalLevel                                           
Invoke-ADDSGetGeneratedNetbiosName                                            
Invoke-ADDSGetNDNCListWithNoOtherReplicas                                     
Invoke-ADDSGetSuitableHelperDomainController                                  
Invoke-ADDSIsDc                                                               
Invoke-ADDSIsRodc                                                             
Invoke-ExpandEnvironmentVariables                                             
Restart-DeploymentTarget                                                      
Test-VerifyADPrepCredential                                                   
Test-VerifyAppPartitionRemoval                                                
Test-VerifyAvailableWinDirSpace                                               
Test-VerifyCertServiceExists                                                  
Test-VerifyChild                                                              
Test-VerifyComputerName                                                       
Test-VerifyComputerWasRenamedAndNeedsReboot                                   
Test-VerifyCurrentUserIsAdministrator                                         
Test-VerifyDCServiceAvailableForDemotion                                      
Test-VerifyDemote                                                             
Test-VerifyDnsConfigOptions                                                   
Test-VerifyDnsDelegationRemoval                                               
Test-VerifyDnsRegistration                                                    
Test-VerifyDomainUpgradeStatus                                                
Test-VerifyForestName                                                         
Test-VerifyForestUpgradeStatus                                                
Test-VerifyFsmoForceRemoval                                                   
Test-VerifyInfrastructureMasterOnline                                         
Test-VerifyIsComputerNameValid                                                
Test-VerifyMachineAdminPassword                                               
Test-VerifyNamingMasterOnline                                                 
Test-VerifyNetBiosName                                                        
Test-VerifyNotInSafeBootMode                                                  
Test-VerifyNtfs5DriveAvailable                                                
Test-VerifyPaths                                                              
Test-VerifyReplica                                                            
Test-VerifyReplicateFromMedia                                                 
Test-VerifyReplicationPartner                                                 
Test-VerifyRequiredPortsAreAvailable                                          
Test-VerifyRODCUpgradeStatus                                                  
Test-VerifySafeModePassword                                                   
Test-VerifySchemaMasterOnline                                                 
Test-VerifySelectedDcAccount                                                  
Test-VerifySiteSelection                                                      
Test-VerifySupportedPlatform                                                  
Test-VerifyTcpIPIsInstalledAndFunctioning                                     
Test-VerifyTree                                                               
Test-VerifyUserCredentialPermissions                                          
Test-VerifyUserCredentials                                                    
Test-VerifyValidRoleChangeState                                               
Add-ADDSReadOnlyDomainControllerAccount                                       
Install-ADDSDomain                                                            
Install-ADDSDomainController                                                  
Install-ADDSForest                                                            
Test-ADDSDomainControllerInstallation                                         
Test-ADDSDomainControllerUninstallation                                       
Test-ADDSDomainInstallation                                                   
Test-ADDSForestInstallation                                                   
Test-ADDSReadOnlyDomainControllerAccountCreation                              
Uninstall-ADDSDomainController                                                

Together with new deployment cmdlets, you now have also a bunch of test-cmdlets which can verify your installation and prove useful during troubleshooting.

We’re facing some exiting times as these new cmdlets will allow you to create more comprehensive scripts. Not only for AD Management, but also for deployment and testing!

Until later!

Blog

Windows 8 Active Directory: New PowerShell Cmdlets

Windows 8 Server will bring a whole lot of changes compared to it’s predecessor: Windows 2008 R2. There has already been a lot of fuzz about these changes, and today I’d like to take a moment and take a look at what new cmdlets we’ve been given to manage Active Directory.

As you all know, Server 2008 R2 gave us the ability to natively manage Active Directory from PowerShell through the AD Module for PowerShell. Unfortunately, not everything could be managed. Although third-party tools (like Quest’s AD cmdlets) made up for it, I always missed the “native” support.

With Windows 8, Microsoft has added quite some new cmdlets to support Active Directory (58 to be exactly), which brings the total amount of cmdlets in the AD Module to 134! Please not that I got this number from the Developer preview and it’s always possible that this amount changes in the RTM-version.

A lot of the new cmdlets fit the gap with before (e.g. AD Replication), others are related to new features as the new claims-based “Dynamic Access Control”.

The following list shows all the cmdlets that have been added:

Add-ADCentralAccessPolicyMember
Add-ADResourcePropertyListMember
Clear-ADClaimTransformLink
Get-ADCentralAccessPolicy                                                     
Get-ADCentralAccessRule                                                       
Get-ADClaimTransformPolicy                                                    
Get-ADClaimType   
Get-ADDCCloningExcludedApplicationList  
Get-ADReplicationAttributeMetadata                                            
Get-ADReplicationConnection                                                   
Get-ADReplicationFailure                                                      
Get-ADReplicationPartnerMetadata                                              
Get-ADReplicationQueueOperation                                               
Get-ADReplicationSite                                                         
Get-ADReplicationSiteLink                                                     
Get-ADReplicationSiteLinkBridge                                               
Get-ADReplicationSubnet                                                       
Get-ADReplicationUpToDatenessVectorTable                                      
Get-ADResourceProperty                                                        
Get-ADResourcePropertyList                                                    
Get-ADResourcePropertyValueType
Get-ADTrust 
New-ADCentralAccessPolicy                                                     
New-ADCentralAccessRule                                                       
New-ADClaimTransformPolicy                                                    
New-ADClaimType            
New-ADReplicationSite                                                         
New-ADReplicationSiteLink                                                     
New-ADReplicationSiteLinkBridge                                               
New-ADReplicationSubnet                                                       
New-ADResourceProperty                                                        
New-ADResourcePropertyList 
Remove-ADCentralAccessPolicy                                                  
Remove-ADCentralAccessPolicyMember                                            
Remove-ADCentralAccessRule                                                    
Remove-ADClaimTransformPolicy                                                 
Remove-ADClaimType          
Remove-ADReplicationSite                                                      
Remove-ADReplicationSiteLink                                                  
Remove-ADReplicationSiteLinkBridge                                            
Remove-ADReplicationSubnet                                                    
Remove-ADResourceProperty                                                     
Remove-ADResourcePropertyList                                                 
Remove-ADResourcePropertyListMember  
Set-ADCentralAccessPolicy                                                     
Set-ADCentralAccessRule                                                       
Set-ADClaimTransformLink                                                      
Set-ADClaimTransformPolicy                                                    
Set-ADClaimType        
Set-ADReplicationConnection                                                   
Set-ADReplicationSite                                                         
Set-ADReplicationSiteLink                                                     
Set-ADReplicationSiteLinkBridge                                               
Set-ADReplicationSubnet                                                       
Set-ADResourceProperty                                                        
Set-ADResourcePropertyList
Sync-ADObject                                                                 
Test-ADServiceAccount  

Note: if you are interested in getting the full list of cmdlets, try running the following cmdlet:

Get-Command –Module ActiveDirectory

To view the total amount of cmdlets, you could easily do the following:

$commands = Get-Command –Module ActiveDirectory
$commands.count

Until later,

Michael

Blog