Recovery Manager for Active Directory Forest Edition – 8.5.1 release is out

Dell Software released Version 8.5.1 of Recovery Manager for Active Directory Forest Edition.

The new release ships with multiple new features which were requested by many customers for a Long time:

Building virtual test environments
In the past the clone wizard provided only limited capabilities to build a test lab on base of our production Active Directory. Now the built-in logic of the Forest Recovery is used to create virtual lab to mirror an existing Active Directory.
The program component Active Directory Virtualization Lab works with MS System Center Virtual Machine Manager, VMWare ESX and VMWare vCenter.

Active Directory management capabilities
The tool now helps to manage Global catalog functionality and FSMO roles throughout your Forest’s domain controller infrastructure

Web Interface

The new Web Interface for Recovery Manager for Active Directory allows you to distribute the tool’s frontend much more easily

Support for BitLocker Drive Encryption when recovering Domain Controllers
If BitLocker is enabled on the domain controllers to be recovered, the tool will take care to disable BitLocker before starting recovery and to enable afterwards.

Enhanced Management Shell
Release 8.5.1 also ships with new Powershell commandlets to manage RMAD activities by script:
Expand-RMADBackup extracts the content of a backup file to a location you can select (same functionality as Extract Wizard from GUI)
Remove-RMADUnpackedComponent cleans up unpacked data from former restore operations
Remove-RMADCollectionItem removes items from a specific computer collection.

With Recovery Manager for Active Directory Forest Edition (RMAD FE) 8.5.1 you can restore Domain Controllers running the following OS Versions:

  • Microsoft Windows Server 2012 (including Server Core installation)
  • Microsoft Windows Server 2008 R2 without Service Pack or with Service Pack 1 (including Server Core installation)
  • Microsoft Windows Server 2008 with Service Pack 1 or Service Pack 2 (including Server Core installation)
  • Microsoft Windows Server 2003 R2 without Service Pack or with Service Pack 2
  • Microsoft Windows Server 2003 without Service Pack or with Service Pack 1 or Service Pack 2

You can install Recovery Manager for Active Directory Forest Edition 8.5.1 on the following platforms:

  • Microsoft Windows Server 2012
  • Microsoft Windows 8
  • Microsoft Windows Server 2008 R2 without Service Pack or with Service Pack 1
  • Microsoft Windows Server 2008 with Service Pack 1 or Service Pack 2
  • Microsoft Windows 7 without Service Pack or with Service Pack 1
  • possible but not recommended:
    Microsoft Windows Vista with Service Pack 2
    Microsoft Windows Server 2003 R2 with Service Pack 2
    Microsoft Windows Server 2003 with Service Pack 2
    Microsoft Windows XP with Service Pack 3

You can view all additional Information on the DELL Website here.

If you need assistance in deploying the Software and set up an Active Directory Forest Recovery plan with this tool, please get in contact here.

How to write or migrate sidHistory with Powershell (2)

SIDCloner.dll
When you look in WWW to find a way to write sidHistory attribute, you probably will stop at the marvelous SID Cloner website created by Jiri Formacek, MSFT (http://code.msdn.microsoft.com/windowsdesktop/SIDCloner-add-sIDHistory-831ae24b). Jiri provides a managed class library that implements the SIDCloner class, which we can use in Powershell and any .NET programming code.
The SID Cloner class is built upon native API to migrate sidHistory and therefore uses the DsAddSidHistory function under the hood (http://msdn.microsoft.com/en-us/library/windows/desktop/ms675918(v=vs.85).aspx).
Although we do not need to install ADMT on any machine to run the SID Cloner code, we still have to consider to meet the same requirements for the migration setup as ADMT does. SID Cloner and ADMT come from the same “mothership” DsAddSidHistory.

SidHistory requirements
In brief we need the following prerequisites to be in place before we can start writing sidHistory (http://msdn.microsoft.com/en-us/library/windows/desktop/ms677982(v=vs.85).aspx):

+ a trust relationship must exist between source and target domain
+ source and target domain must not be in the same Active Directory forest
+ for source domain all actions will have the PDC Emulator as target; you cannot bind to another DC than the one with the PDC Emulator role
+ Auditing must be enabled in source domain
+ a domain-local group “domain$$$” must be created in source domain
+ a special registry key must be created on PDC Emulator DC in source domain: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\TcpipClientSupport
+ Audit Mode must be turned on in each domain and also Account Management auditing of Success/Failure events must turned to on.
+ the Security Identifier we want to transfer must not already exist in any sidHstory attributes of objects in target domain

Permissions:
For running Powershell code based on SID Cloner you do not necessarily need domain admin credentials in target domain. While read permissions on objects in source domain are sufficient (you are reading the “standard” attribute objectSID there), the permissions to modify the object in target domain by writing the sidHistory value requires more:
+ full access permissions to the object (better OU)
+ special permission “migrateSIDHistory” on the Active Directory domain object in target domain
migrateSidHistoryPermission

With all the requirements settled, you are able to migrate sidHistory by using the sample script, that Jiri published on the SID Cloner Website.

However, the most easy way to use the 4 fold overload with SIDCloner did never work in our tests.
Overload with 4 arguments means, you simply define source and target domain, source account from which you want to take the objectSID and target account where you want to write sidHistory.
This approach will probably never succeed because
a) the strict PDC Emulator access is not guaranteed when using a domain call
b) the credentials of the interactively logged user are obviously not passed to the DsAddSidHistory function inside the SID Cloner dll

Let’s have more findings around this Topics in Part 3 of this blog post.

 

How to write (migrate) sidHistory with Powershell (1)

The adventure of sidHistory
I spent quite some hours during the last weeks to create a Powershell script routine that is able to “migrate sidHistory”. Migrate sidHistory in this context means to read the objectSID of a given user or group source object in Active Directory Forest A and write this value into the sidHistory attribute of a selected user or group object in Forest B.
Assuming there is a trust relationship between Forest A and Forest B and sidFiltering is disabled, user B from Forest B who has the sidHistory attribute filled with the SID of the user A from Forest A will have access to the same resources in Forest A like user A himself. The reason for this behavioris found in the fact that the security token of User B after successful logon will contain the SID of user A. From Windows’ token based access strategy, user B is now a user AB as long as we are talking about SID releated resource access.
From those few lines everyone agrees on the statememt that sidHistory functionality can be abused to get access to resources which are restricted for a user by default. In principle, you can add the SID of a given user from Forest A to any user in Forest B. There does not have to be a dedicated relationship like identical samaccountname of the two users (groups) etc. While exactly his functionality helps to ease Inter-Forest Active Directory migrations (and Intra Forest Migrations as well when you take care), it can also be a dangerous thread against your Active Directory security.
However, this not a new finding and Microsoft did well in treating sidHistory as a special attribute. It needs special treatment when you try to clear the values and it needs special treatment when you want to write values into it. I already published 2 posts about deleting sidHistory, see [Link], so we will concentrate here on writing sidHistory.

Writing sidHistory
The most common way in today’s Active Directory migration scenarios is writing sidHistory by using a migration software. Microsoft ships its own migration software called Active Directory Migration Tool (ADMT) which is capable of writing sidHistory. Other vendors like Dell Software’s Migration Manager for Active Directory (formerly known as Quest Migration Manager for Active Directory) provide a similiar functionality with a lot more options and the possibility to write sidHistory in an ongoing Active Directory Synchronization. Up to now Microsoft Forefront Identity Manager cannot help us here out of the box to fill this attribute as part of an Active Directory synchronization.
When you try to put a SID into the sidHistory attribute by using the standard Microsoft administrative tools like the attribute editor from ADUC, you will fail for sure.

errorsidhistory

You will also fail by using Powershell integrated LDAP based write operations for this attribute like set-aduser or set-qaduser.

errorsidHistory_a

We have to dig deeper here to reach our goal of Powershell based writing of sidHistory, which we will do in Part 2 of this blog post.

Coexistence Manager for Notes – new release 3.5.1

Dell Software released a new version of Coexistence Manager for Notes(R). Coexistence Manager for Notes version 3.5.1 provides coexistence between Exchange and Notes E-Mail Systems and eases migration activities in large scale infrastructures.
New features include:
• Expanded Free/Busy support to include Lotus Domino 8.5.3 FP2
• Improved message conversion provides more robust coexistence with Exchange 2003
• More granular control of object names when Directory Connector performs an update
• Improved HTML fidelity for Outlook 2003 users

News for the Exchange Professional (2): High Level Exchange events – Autumn Ignite Summits

Exchange Product Group announced and recommended the Ignite Summit events, which are held in 4 location around the globe:
Hong Kong, 7-10, 2013
Prague, Oct 21-24, 2013
Washington DC, Nov 4-7, 2013
Dubai, Nov 18-21, 2013

The 3 days track of session is designed and delivered by product experts from across Microsoft (Engineers, Technical Writers, Product Managers & Consultants). The over 70 session cover topics from Office, Office 365, SharePoint, Exchange, Project, Yammer and developer content.

The Ingnite Exchange Track comes with this agenda actual:
Day 1 Ignite Keynotes
Exchange Architecture
Exchange Deployment & Coexistence
Storage, High Availability & Site Resilience
Day 2 Exchange Managed Availability
Exchange Server Sizing & Performance
Exchange Server 2013 Virtualization Best Practices
Collaboration with Exchange
Exchange Online Hybrid Migration
Day 3 Archiving, eDiscovery & DLP
Exchange Online Protection Overview
Implementing Exchange Online Protection
Exchange Tips, Tricks and Troubleshooting

Microsoft Partners register here.
Not Microsoft Partners register here.

ignite