Installing and configuring Azure Active Directory Sync and use IDFIX

To install Azure Active Directory Sync , we will have to prepare prerequisites

https://technet.microsoft.com/library/jj151815.aspx?f=255&MSPPError=-2147217396#bkmk_installmodule

To prepare Azure Active Directory Sync Server, you will need to download the following tools to check for users attributes on your local AD:

  1. Mirosoft Windows Server 2008R2/2012R2
  2. NetFramework 4 (For IDFIX tool to work)
  3. IDFIX (to Check if there’s any issue on AD with DirSync)

Note:

One of the new features that came with AADSync is that it can be installed on the DC server as well. but some may choose to have it on a separate server to avoid any risk.

 

Software Prerequisites

Install required tools for Azure Active Directory Connector (Dirsync)

  1. AADSYNC latest version (Download here) (Version Review link)
  2. Microsoft Online Services Sign-In Assistant for IT Professionals RTW (Here)
  3. Azure Active Directory Module for Windows PowerShell (64-bit version) (Here)

clip_image001

 

Additionally, to connect and synchronize to Office 365, the following prerequisites need to be installed before installing AADSYNC…

Install “Windows Azure Active Directory Module for Windows PowerShell (64-bit version)”.  It is highly recommended that this machine be restarted before installing DirSync.

 

NOTE: Effective October 20, 2014, the 32-bit version of Azure Active Directory Module for Windows PowerShell is discontinued. Support for the 32-bit version will no longer occur, and future updates to the Azure Active Directory Module will be released only for the 64-bit version. We strongly recommend you install the 64-bit version to ensure future support and compatibility. Refer to “Install the Azure AD Module” in Manage Azure AD using Windows PowerShell.

 

If DirSync is to be installed on a server with Windows 2008 R2, beginning with version 1.0.6765.0006, PowerShell 3.0 is required and can be installed from Windows Management Framework 3.0; AND beginning with version 1.0.6985.000, .NET Framework 4.5.1 is a prerequisite.

 

From <https://oddytee.wordpress.com/2014/03/11/requirements-for-dirsync/>

 

Installing Netframework 4.5

clip_image002

clip_image003

 

Once you download IDFIX, you have to unzip and run the exe tool

Right click on Idfix and run it as administrator to give it the required privileges to access AD users and groups.

image

 

After you run it, it must look like the following

clip_image004

 

After running the tool you will have to click on Query to get the problematic users/groups and solve the ones that you want them to be synced to Office 365 Azure AD.

Top Level Domain:

The most common issue that occurs when preparing for AADSYNC is the Top Level domain users related errors (If .local is used)

clip_image005

To Fix this issue for all the users/groups which will be synced to O365 you will have to open Active Directory Domains and Trusts:

Right click on Active directory domains and trusts and click properties then add your public domain to the Alternative UPN Suffixes:

image

image

 

Next open Active directory users and computers to change the UPN to the correct one that matches your public domain.

Note:

Changing the domain suffix for your users suffixes won’t affect their login to their machines or any other application server.

 

image

 

Select the users in which OU that you want it to be synced and right click and choose Properties.

image

 

image

 

image

 

Proxy Address:

You might as well face another issue with users that you intend to sync to Office 365 which is the SMTP proxy address. in some Exchange Organizations the e-mail policy might be set wrong and therefore the user might have an invalid domain value in his proxyaddress attribute e.g. user@domain.local

 

To solve this, there are 3 ways to solve it. First would be to use Exchange on-premises Email policy to delete the .local SMTP proxy and set the public domain one.

The other two ways would be that you delete the proxyaddress manually or with a powershell script . I personally prefer to do this manually due to avoid any risk that it may impose on the users objects.

Another method would be the IDFIX it self or Admodify.

In the below snapshot I used IDFIX to fix the proxyaddress of the problematic users.

clip_image008

 

Installation of ADDSYNC 

First we’ll install Microsoft Online Services Sign-In Assistant for IT Professionals RTW…

clip_image009

Next Windows Azure AD powershell module

clip_image010

Installing AADirsync

clip_image011

clip_image012

clip_image013

clip_image014

clip_image015

In the next step you will have to enter an Office 365 Global administrator user (preferably not onmicrosoft.com user) and I would recommend that you create a cloud user on Office 365 with global admin privileges to use with AADSYNC.

clip_image016

Next before you continue, you should open your O365 portal and Enable ADSync there.

image

When you click on Set up the following page should come to you. you should click on Activate AD Sync.

clip_image018

clip_image019

 

Now you may continue to config AADSYNC, below I am going to use a different user that’s dedicated only to “AADSYNC” tool. I will calll it Dirsynccloud@domain.com

 

image

 

Next On Active directory on-premises I will configure a new user called (Dirsync) that’s member of enterprise admins. this user will have access to all the OUs that will be synced in order to sync their attributes and passwords..etc

image

 

Once you enter your Enterprise domain account below and click add forest, it will be enlisted below and you can add additional number of forests if you have more.

 

image

clip_image025

 

Next you may choose to have Hybrid deployment if you have Exchange on-premises (At least Exchange 2010 SP3) but if not then no need to tick the box. The password write-back is a feature that requires an Azure premium AD subscription so if you don’t have this subscription then you don’t really need to tick this box.

 

The Azure AD app and attribute filtering is a feature that allows you to pick a certain application attribute you want to sync back and forth to Azure AD e.g. (Exchange, SharePoint..etc). If you don’t tick this box the normal standard attributes will be synced which will include (Exchange and user’s basic info) you can find it as soon as the setup finished and you open ADDSync UI.

 

clip_image026

Password writeback overview

Password writeback is an Azure Active Directory Sync component that can be enabled and used by the current subscribers of Azure Active Directory Premium. For more information, see Azure Active Directory Editions. It allows you to configure your cloud tenant to write passwords back to you on-premises Active Directory. It obviates you from having to set up and manage a complicated on-premises self-service password reset solution, and it provides a convenient cloud-based way for your users to reset their on-premises passwords wherever they are. Read on for some of the key features of password writeback:

From <https://msdn.microsoft.com/en-us/library/azure/dn903642.aspx>

You can enable filtering in AADSync at any time. If you have already run the default configurations of directory synchronization and then configured the filtering, the objects that are filtered out are no longer synchronized to Azure AD. As a result, any objects in Azure AD that were previously synchronized but were then filtered are deleted in Azure AD. If objects were inadvertently deleted because of a filtering error, you can re-create the objects in Azure AD by removing your filtering configurations, and then synchronize your directories again.

From <https://msdn.microsoft.com/en-us/library/azure/dn801051.aspx>

image

 

Next I will not tick Synchronize now because this will sync All local AD objects and OUs to the cloud, in my case I just want to choose particular OUs to sync to the cloud.

 

clip_image029

 

In order to configure AADSYNC to choose which on-premises Active directory Organization Unit you want to change you will have to navigate to the following path on the server which you installed AADSYNC.

PATH:

C:Program FilesMicrosoft Azure AD SyncUIShellmiisclient.exe

Right click on domain.local and click properties

image

Next Click on “Configure Directory Partitions” and Under “Credentials” Click on Containers and enter your new on-premises enterprise admin account.

image

 

Next select the OU you want to sync to the cloud and click OK

image

 

Next you will want to open “Task Scheduler” on the server and Enable the task that was created by AADSYNC installation to enable every 3 hours sync..

image

 

In order to Force the sync you will have to run a separate command that Microsoft has brought along with AADSYNC called “DirectorySyncClientCmd” the command can be run from Powershell or made a shortcut on a desktop and directly run.

Path:

c:Program FilesMicrosoft Azure AD SyncBinDirectorySyncClientCmd

 

Hope you find this useful. Winking smile 

Active Directory Migration 2003 to 2012 R2

Current Environment

Microsoft Active Directory 2003 with Exchange 2010

 

Requirements for migration

1- New Windows Server 2012 R2 server to be prepared. 

2- Join the new Server to the old Dc.

 

 

Installing DC role

clip_image001

clip_image002

clip_image003

clip_image004

clip_image005

clip_image006

clip_image007

clip_image008

clip_image009

clip_image010

 

to migrate the AD Operations Master roles.  The simplest way to move these roles is via PowerShell.  On Server 2012 AD PowerShell modules, this can be done from anywhere.  Simply run the following command to view you current configuration, and change them:

 

PS C:> netdom query FSMO

 

clip_image011

 

Move-ADDirectoryServerOperationMasterRole -identity “dc1” -OperationMasterRole 0,1,2,3,4

 

clip_image012

 

clip_image013

 

Making sure that all the roles have been migrated :

 

netdom query FSMO

 

clip_image014

clip_image015

Adding second DC

clip_image016

Reference:

https://technet.microsoft.com/en-us/library/ee617229.aspx?f=255&MSPPError=-2147217396

Source: Default-First-Site-NameDC2

******* 1 CONSECUTIVE FAILURES since 2015-03-23 19:37:45

Last error: 8524 (0x214c):

The DSA operation is unable to proceed because of a DNS lookup failu

re.

Naming Context: CN=Configuration,DC=kibtek,DC=local

Source: Default-First-Site-NameDC2

******* WARNING: KCC could not add this REPLICA LINK due to error.

Naming Context: CN=Schema,CN=Configuration,DC=kibtek,DC=local

Source: Default-First-Site-NameDC2

******* WARNING: KCC could not add this REPLICA LINK due to error.

Naming Context: DC=kibtek,DC=local

Source: Default-First-Site-NameDC2

******* WARNING: KCC could not add this REPLICA LINK due to error.

clip_image017

Resolution:

After joining new DC you will see this error until the replication with the PDC and schema master is finished.

Use the repadmin /syncall to hasten the sync process.

clip_image018

After we changed the PDC and Schema master role server to the new DC and shut down the old DC for test. On Exchange 2010 server you might get the following error

Exchange Console

clip_image019

Current deployment

  1. Exchange 2010
  2. New DC 2012 R2 with another Additional DC installed newly.
  3. Two DC 2008R2 but have been shut down for testing.

Problem:

After you shutdown or demote the old PDC or Schema master Demote Domain Controller role, Microsoft Exchange Management Console fails to retrieve any Exchange information with error message “An error caused a change in the current set of Active Directory Server settings. Restart Exchange Management console.”

Cause

Microsoft Exchange management console caches the data in the user’s profile for quick access, So whenever you try to open EMC from an existing Exchange admin profile you will get the same error.

Resolution:

Navigate to the following folder and delete the Exchange Management Console file.

{308b10a016e19a1cd6a208cbc3961927e16fc6766a4020d3c4ef54ea17925f0f}userprofile{308b10a016e19a1cd6a208cbc3961927e16fc6766a4020d3c4ef54ea17925f0f}appdataroamingMicrosoftMMCExchange Management Console

clip_image020

Close EMC and reopen it and you should be done.

 

Hope this was useful Smile 

del.icio.us Tags: ,

Domain Controller Cross Forest migration Part 3 (ADMT Installation)

ADMT 3.2 installation

 

Requirements

  1. SQL express/full 2008 sp2
  2. Windows 2012/R2 / Windows 2008 R2 for ADMT
  3. Install PES on Source DC for Migrating Passwords

http://blogs.technet.com/b/askds/archive/2010/07/09/admt-3-2-common-installation-issues.aspx

  • The server where you install ADMT can run any supported version of Windows Server, including Windows Server 2012 R2 and Windows Server 2012.
  • The source and destination domain controllers must be writeable, but they can run any supported version of Windows Server with a user interface (not Server Core), including Windows Server 2012 R2 and Windows Server 2012.
  • The source and destination domains must be at Windows Server 2003 domain functional level or higher.
  • The computers that can be migrated can run any supported version of Windows, including Windows 8.1.
  • You can use any version of SQL Server for the ADMT database.

From <https://technet.microsoft.com/en-us/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx>

 

ADMT user permissions:

image

From <https://social.technet.microsoft.com/Forums/windowsserver/en-US/fe44cdd4-ef11-4d73-801d-f37939d756bd/minimum-permissions-needed-for-admt-32-when-doing-an-interforest-migration-with-sid-history?forum=winserverMigration>

 

ADMT Migration Account

The account you run ADMT under will need to have administrative rights in both the source and destination domain. You may decide to create a user specifically for the ADMT Migration, or you may use an existing user e.g. the default administrator account. I will create a user called ADMT and assign this user the correct permissions. This is the account we will use for the entire migration.

It is recommended that you make the user account in the destination domain and make it a member of the domain administrators group.

destination Domain:

clip_image001

 

In the source domain add the same user to the builtin administrators group (you will be unable to add it to the domain administrators group).

Source Domain:

 

clip_image002

 

Installing ADMT

You should install ADMT and SQL onto a member server in the destination forest. Use the ADMT service account explained in the previous post to install SQL and ADMT.

ADMT requires a preconfigured instance of SQL Server for its underlying data store, so we’ll go ahead and install SQL 2008 SP1 Express on ADMT.contoso.com

 

Installing SQL Express 2008 SP2

SQL Express download here: https://www.microsoft.com/en-us/download/details.aspx?id=30438

clip_image003

clip_image004

clip_image005

clip_image006

Cause

This error is purely within SQL Express 2008 and is not really to do with ADMT 3.2. The issue is fixed in “Cumulative update package 4 for SQL Server 2008”.

Unhelpfully, this error is identified in KB975055 as being only for Windows 7 and that it was fixed by SP1 – both incorrect. The issue does affect Win2008 R2 and is only fixed by the cumulative update.

Resolution

Before installing SQL Server Express 2008 with SP1 (which will fail), first install:

Cumulative update package 4 for SQL Server 2008 

http://support.microsoft.com/kb/963036

clip_image007

clip_image008

clip_image009

clip_image010

clip_image011

clip_image012

clip_image013

clip_image014

Set an account for the SQL service to run under (use your ADMT Service Account).

clip_image015

Set a SQL administrator, choose the user account you plan to run ADMT under- be aware that this user account will need to have local administrative rights in the source domain (this will be discussed further in the series).

clip_image016

clip_image017

Download ADMT 3.2

https://onedrive.live.com/redir?resid=82488EABA4ACDB15!33497&authkey=!AF3kLtU8fl2_B0I&ithint=file{308b10a016e19a1cd6a208cbc3961927e16fc6766a4020d3c4ef54ea17925f0f}2cexe

Installing ADMT

For this series I will be using ADMT 3.2, which is the supported version for Server 2008 R2. Use ADMT 3.1 for installation on a Server 2008 non-R2 server, or ADMT 3.0 for Server 2003. If you need to migration a Server 2000 Domain, you will need to use ADMT version 3.1 or earlier.

Update Junes 2014 – ADMT 3.2 now supports Windows Server 2012 / 2012 R2.

clip_image018

clip_image019

clip_image020

clip_image021

clip_image022

clip_image023

clip_image024

clip_image025

 

 

Hope this helps, please stay tuned for the next part. Winking smile 

 

Office 365: Add additional accepted domain to SMTP Address

 

If you have configured Hybrid integration between Exchange 2010/2013 with Office 365 using dirSnyc or Azure active directory sync tool and then stopped the synchronization. The accepted domains and additional domains will be removed from the user’s Attributes on the cloud and in order to add these accepted domains again to all of the Office 365 users..

 

First we’ll have to connect to Exchange online with the following powershell tool. so Launch Azure powershell as Admin and copy the following line by line.

 

1- $UserCredential = Get-Credential

2- $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

3- Import-PSSession $Session

 

image

 

First we’ll show/view user’s existing SMTP addresses, in order to do so we’ll use the following PowerShell cmdlet

 

For all users

4- Get-Mailbox | fl –property Alias, WindowsLiveID, EmailAddresses

 

Get-Mailbox –Identity user@domain.com | fl –property Alias, WindowsLiveID, EmailAddresses

For one user

image

 

Procedure to add an additional accepted domain to all users in the Office 365 tenant.

 

Note:

The domain must be verified on Office 365 first before applying those steps

 

1-

$users = Get-Mailbox

image

2-

foreach ($a in $users) {$a.emailaddresses.add(“smtp:$($a.alias)@AdditionalDomain.com”)}

image

3-

clip_image003

$users | {308b10a016e19a1cd6a208cbc3961927e16fc6766a4020d3c4ef54ea17925f0f}{Set-Mailbox $_.Identity -WindowsEmailAddress $_.WindowsEmailAddress}

 

Hope you find this useful.

Search for users start with particular letters in the display name

 

To search your Office 365 users with particular initial characters

First connect to Microsoft Online Service

 

clip_image001

 

To Search for users whom their display names contain “Top” you can use the following powershell

get-msoluser -all | where-object {$_.displayname -like “top*”} | ft displayname,userprincipalname,proxyaddresses

 

image

 

Search for users whom their UPN contains “TOP” in the start

get-msoluser -all | where-object {$_.userprincipalname -like “top*”} | ft displayname,userprincipalname,proxyaddresses

 

image

Hope this helps Smile 

 

Export users licenses and information O365

In order to Export users licenses and information from Office 365 you will have to use the following script.

 

First you will need to connect to MS Online service with a Global admin account

Connect-MsolService

image

 

Get-MsolUser -All |Where {$_.IsLicensed -eq $true } |Select DisplayName,UsageLocation,@{n=”Licenses Type”;e={$_.Licenses.AccountSKUid}},SignInName,UserPrincipalName,@{n=”ProxyAddresses”;e={$_.ProxyAddresses}}| Export-csv -Path C:ExportlicenseUsage.csv –notype

 

clip_image001

 

This will export a file called “ExportLicenseUsage.csv” to your C root drive. you can open this file with Microsoft Excel and find out all the useful information that you’re looking for.

Hope this helps Smile 

 

Testing Office 365 SMTP relay

In order to test Office 365 SMTP relay you will have to create a user with an Exchange online license. After the email is activated for this user you can test this user for relay with the following powershell.

 

First connect to Microsoft Online service with this user that you’ll be using for relaying.

$msolcred = Get-Credential

 

Next edit the following powershell with the user’s e-mail and the recipient’s too

Send-MailMessage –From RelaySMTPuser@domain.com –To destinationuser@gmail.com –Subject “Test Email” –Body “Test SMTP Relay Service” -SmtpServersmtp.office365.com -Credential $msolcred -UseSsl -Port 587

 

clip_image001

 

clip_image002

 

https://technet.microsoft.com/en-us/library/dn554323(v=exchg.150).aspx

 

This test is known as Client SMTP submission you can also use a different method for multiple devices where you can configure them all to point to a single server (IIS) in a method known as IIS for relay with Office 365 however, all the methods what involve office 365 (Only) for relay will require a user with Exchange online license assigned to it.

 

https://technet.microsoft.com/en-us/library/dn592151{308b10a016e19a1cd6a208cbc3961927e16fc6766a4020d3c4ef54ea17925f0f}28v=exchg.150{308b10a016e19a1cd6a208cbc3961927e16fc6766a4020d3c4ef54ea17925f0f}29.aspx

 

Hope this helps Winking smile

 

Domain Controller Cross Forest migration Part 2

Current environment on the LAB.com DC

  1. Additional DC2
  2. SCVMM
  3. SCVMM SQL
  4. Exchange
  5. SCMM
  6. SCMM SQL

Computers

clip_image001[7]

 

Migration plan

AD 2012 R2 (LAB.com) to (Contoso.com) 2012 R2.

Users

 

clip_image002[6]

 

In the second part of this series (DC cross forest migration) I will demonstrate some major required steps for the migration from the old DC (lab.com) to the new DC (Contoso.com)

NOTE:

SQL Servers and their applications can’t be migrated due to SQL permissions and Schema mismatch.

 

Requirements are :

Destination DC Forest Function and domain function level must be set to at least 2008 R2 for ADMT3.2 to work

 

clip_image002[4]

 

And a health check must be performed on the FSMO roles to make sure everything is functioning properly on the Source DC..  PDC, SchemaMaster..etc

The checks I will perform are

  1. Check replication (In case there’s more than one DC In the source forest).
  2. DC health (DCDiag tool)
  3. Check the reachability of the PDC.

 

Netdom query FSMO ( this command will show you which DC in the source forest holds the roles exactly)

 

clip_image001[5]

 

1- For Checking replication you can use the repadmin command line which checks replication between sites, DCS and reports any errors in between. in case you have one server in pace the following outcome should be printed for you.

Repadmin.exe helps administrators diagnose Active Directory replication problems between domain controllers running Microsoft Windows operating systems.

https://technet.microsoft.com/en-us/library/cc770963.aspx

 

image

 

2- Check DC health using DCDIAG tool

Analyzes the state of domain controllers in a forest or enterprise and reports any problems to help in troubleshooting

https://technet.microsoft.com/en-us/library/cc731968.aspx

as they are multiple types of tests that can be applied with dcdiag depending on the parameter used. I will start with the DNS.

image

 

If the DNS is healthy then it should show as following. and we can continue to the next test.

image

For an extensive test, you can use the parameter /v along with this sign >c:dcdiag.txt to export the test to a file and look at it line by line.

image

 

If everything sounds good and healthy we shall move on to the next step which is DNS configuration


DNS Configuration

Preparation:

  1. DNS replication between both domains
  2. Installing Windows 2008 R2 for ADMT 3.2
  3. Setting up domain trust between forests.

 

 

  1. DNS replication between the source and target domain

In order for the trust to be created between both forests, you either have to create a conditional forwarders that will copy the source zones to the destination DNS server and vice versa or you can create a secondary forwarder zone in destination DC for the source DC and vice versa.

In my case I will go for creating a secondary zone and to do this I will go to each DNS server and allow Zone to be transferred.

Note:

You can include only the IPs of the Source and Destination servers in the zone transfer and any additional DNS servers.

clip_image003[7]

 

Now I a have created a secondary zone DNS and trying to resolve FQDNs from the source server as in the below snapshot.

 

clip_image004[7]

 

Same will be done on the destination server.

 

clip_image005[7]

 

Checking Name Resolution for both domains:

 

clip_image006[7]

 

Once the nslookup works as expected from both servers then we’ll ahead with creating forest trust between both DCs.




Creating Forest trust between Source and Destination Domain.

NOTE:

In order for the trust to be created between both source and destination domains the PDC on the Destination Domain must be available.

 

1. Open the Active Directory Domains and Trusts, right click on the domain and click properties.

 

clip_image011[4]

clip_image012[4]

clip_image013[4]

clip_image014[4]

clip_image015[4]

clip_image016[4]

clip_image017[4]

clip_image018[4]

clip_image019[4]

clip_image020[4]

clip_image021[4]

clip_image022[4]

clip_image023[4]

clip_image024[4]

 

We will have to validate trust after creating it to make sure that trust in both ways are validated.

 

clip_image025[4]

 

clip_image026[4]

 

clip_image027[4]

 

Now since trust is created and already validated both ways, we’ll have to add a GPO policy to update all clients with the new Domain name in the DNS suffix search list to resolve netbios names.


Updating DNS Suffix Search list:

 

DNS suffix search list:

In order to add the source and destination domains suffix to the dns suffix search list we will have to open GPO on the destination Domain (Contoso.com)

 

clip_image028[4]

 

On the target domain (contoso.com) we’ll have to open GPO .

Right Click on default domain policy / Edit

 

clip_image029[4]

Go to (Computer Configuration Policies Administrative Templates Network DNS client

Double click on the DNS Suffix Search list to open it and enable it.

clip_image031[4]

image

Click ok and apply the police and see how it should show in the report.

clip_image033[4]

 

Once this is done and policy is applied among all clients you should have no problem and it should show first on the DC where you applied the policy.

 

image

 

Hope you find this helpful and stay tuned for the next part. Winking smile 

 

del.icio.us Tags: ,,

Domain Controller Cross Forest migration Part 1

In this series of articles I will demonstrate the Cross forest migration for Microsoft Windows Active directory 2012 R2.

 

Before starting any step, I will have to do a revision for the current environment and check what is there, what can be migrated and what can not be.

 

Revisions:

  1. Check if the environment is using an old cryptographic algorithms that’s not supported during the migration .e.g. (SHA-1 1024bit Certification authorities).
  2. Notice that Group Policy user profile folder redirection might have a bug from SCCM. To fix this the SCCM needs to be checked for one option needs to be disabled

Under the SCCM Configuration manager,

– Select Administration

– Select Client Settings

– Pull up PROPERTIES of Default Client Settings configuration and click on Compliance Settings

 

From <http://blogs.technet.com/b/askds/archive/2013/12/13/an-update-for-admt-and-a-few-other-things-too.aspx>

 

– Enable User Data and Profiles mentioned above is the setting which drives the control of Folder Redirection and Remote User Profiles.
The above configuration by Default is set to NO. Once enabled (set to YES), it passes the control of Folder Redirection, Offline Files, and Remote User Profiles to WMI and stores this configuration under the registry path: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUserStateUserStateTechnologiesConfigurationControls

  1. TCP/IP crashes and errors: Hotfix released to correct a crash in TCP/IP.

 

Ref:

http://blogs.technet.com/b/askds/archive/2013/12/13/an-update-for-admt-and-a-few-other-things-too.aspx

 

Hardware Requirements

  1. Windows 2008 R2 DC on the destination forest.
  2. Windows 2012 R2 ADMT and SQL express 2008 R2 or 2012 R2 express or full.

Reference:

https://support.microsoft.com/en-us/kb/2753560

 

Software Requirements

1- Rights Management Services Analyzer Tool

 

From <http://www.microsoft.com/en-us/download/details.aspx?id=46437>

RMS Analyzer provides the following features:

• Support for Azure RMS and AD RMS diagnostics

• Prerequisite checks for Azure RMS integration (such as any required hotfixes, registry key settings, Microsoft Online Sign-In Assistant)

• Ability to collect trace logs to capture real-time problems

• Diagnostics and remediation for Office 2013 and Office 2010

• Basic diagnostics for federation services

• Group membership check, based on groups and policy templates

• Display of your RMS configuration settings and verification tests to validate service health for RMS

• Ability to monitor multiple servers and find all RMS servers in trusted forests

By installing and using the software you accept the License terms which are located in the zip folder download. If you do not accept the terms, do not install or use the software.

2- Password Export Server (PES) – x64

http://www.microsoft.com/en-us/download/details.aspx?id=46437

 

3- Active Directory Migration Tool (ADMT) QFE – x86

https://connect.microsoft.com/site1164/content/content.aspx?ContentID=30561&IsDraft=False>

 

I will publish the next parts as soon as I am done with them. stay tuned Winking smile