Welcome to TechNet Blogs Sign in | Join | Help

We have been asked by a couple of customers whether it is possible to turn off the use of encrypted RPC by the DFS Replication service. Some of these customers were evaluating WAN acceleration solutions which do not work well with encrypted RPC traffic. Let us try to understand why the DFS Replication service uses encrypted RPC and whether there is any benefit to turning it off from a WAN traffic acceleration perspective.

 

The DFS Replication service uses Remote Procedure Calls (RPC) over TCP to replicate data. Since the service has been designed to use the Remote Differential Compression (RDC) algorithm and since it uses XPRESS compression to compress data prior to transmission, it transfers only a compressed diff over the wire. This means that only the changed blocks between files are compressed and transferred over the network, instead of the entire file being transferred.

 

In other words, the replication protocol itself has been designed to be WAN friendly and to work in high latency scenarios while keeping bandwidth consumption to a strict minimum. Hence, there are no tangible benefits of deploying a WAN acceleration solution in conjunction with the DFS Replication service. Also, in the interest of securing data transfers over the wire, the DFS Replication service has been designed to always use RPC_C_AUTHN_LEVEL_PKT_PRIVACY, thus ensuring that RPC communication over the wire is always encrypted.

 

To summarize, it is not possible to disable the use of encrypted RPC by the DFS Replication service. The DFS Replication service is designed to be efficient over the WAN as a result of the use of RDC in conjunction with XPRESS compression.

 

-------

Mahesh Unnikrishnan

It’s very common for a server running Windows Unified Data Storage Server and the Microsoft iSCSI Software Target to include a RAID controller and many hard drives in the box. I got a question on exactly how to configure RAID volumes for this kind of setup. The standard “it depends” engineering answer does apply here. However, allow me to elaborate on that :-).

 

To see the full post, visit http://blogs.technet.com/josebda/archive/2008/05/07/raid-configuration-options-for-wudss-and-the-microsoft-iscsi-software-target.aspx 

 

Jose Barreto

A number of third-party blogs are telling people they can speed up Windows Update downloads, and file copy operations, by turning off the Remote Differential Compression (RDC) feature on Windows Vista. This is 100% false. Neither Windows Update or file copy operations use RDC at all.


The RDC feature is simply a DLL that does not consume any system resources, except when you run an application that uses RDC specifically. If you disable RDC, any application that uses it will either not be able to take advantage of RDC or will simply fail. For more information on RDC see this link http://msdn.microsoft.com/en-us/library/aa373254(VS.85).aspx.

  

--Diane

 

Are the Backups secured?

Yes. The Complete PC Backup (CPC) or Windows Server Backup (WSB) can be only invoked by a user belonging to either Administrators or Backup operators Group.

§  Disk:

Backups are ACLed to be accessible only for only Administrators and Backup Operators Group.

§  Network:

By default the Backups inherit the ACLs from its parent directory;

However if an user chooses to ACL the Backups strongly, the Backups would be ACLed to be accessible only to the user whose credentials are provided at the time of Backup rather than inheriting from the parent;  Also the Backups are acled for Administrators and Backup Operators of the machine which hosts the Network Share.

§  Optical:

The Backup is done after the media is formatted to UDF format which doesn’t support ACLs. So The Backup to Optical Media is only as secure as the physical media.

§  Removable:

The Backup is done after the media is formatted to NTFS format and the Backups are ACLed to be accessible only for Administrators and Backup Operators group.

 


Can I additionally secure the Backups by backing up to an encrypted folder (Creating Encrypted WindowsImageBackup directory in the root of the volume or in network share and backing up to the volume or the network share)?

No. Backup to a target which is encrypted at file system level is not allowed.

If you attempt the same, you would be getting following the error message:

“Backups cannot be stored on an encrypted volume. Please decrypt the volume and retry the operation”

 


Can CPC or WSB backup the Systems protected by BitLocker?

 

Yes. You can use CPC or WSB to backup your systems protected by BitLocker.

Additionally you can secure the Backup Target Disks too by protecting the same with BitLocker.

Ensure the volumes which are backed and the Backup Target, if BitLocked are unlocked for Backups to succeed.

                               


Are the Backups of volumes which are protected by BitLocker encrypted?


No. The Backups of volumes which are protected by BitLocker aren’t encrypted. Backup reads the data blocks from VSS Shadow created on the volume which is a clear text. Hence Backups are not encrypted.


To secure the Backup data in case of System or Backup Target being stolen or lost, the Backup target if it is a disk, can be secured using BitLocker protection. So if you are restoring your system from the Backup (Bare Metal Recovery), post recovery the volumes which were BitLocked when the backup was taken would not be BitLocked. Hence you would need to BitLock the volumes again.

 

 

If the Source Volume(s) or Backup Target is BitLocked, do I need to do any additional steps during System Restore(Bare Metal Recovery) or in Online Recovery?

 

For Any type of Recovery ensure that the Backup Target if BitLocked is unlocked. If the Recovery is a file-level recovery (File Recovery, App Recovery, System State Recovery) the Recovery Target too needs to be unlocked if it is BitLocked. However unlocking a locked BitLocked Recovery Target is not needed if the Recovery is a volume-level recovery (Volume Recovery, System Recovery(Bare Metal Recovery))

 

 

Appendix:

Encrypted File System (EFS) and BitLocker links:

http://technet.microsoft.com/en-us/magazine/cc138009.aspx

http://www.microsoft.com/technet/security/guidance/clientsecurity/dataencryption/default.mspx

http://www.microsoft.com/technet/security/guidance/clientsecurity/dataencryption/analysis/80c0d0af-2c2e-45d6-9b29-f850926296bb.mspx

 

Acronyms:

CPC – Complete PC Backup in Vista and Vista SP1

WSB – Windows Server Backup of Longhorn Server 2008

 

- GeethaKrishna S

April is a busy month. We just had the MVP Summit here at our home at Microsoft Redmond campus. The event was so successful we decided to post some information about this in the blog!

 

But what are MVPs?

MVPs are Microsoft Most Valuable Professionals, independent community leaders and IT Professionals. They are awarded for their outstanding community contributions in the past 12 months. The award is a big recognition – there are hundreds of millions Microsoft users around the world, but only 3 thousand MVPs!

 

MVPs are very important to our team and to Microsoft. First, their contributions help Microsoft users all around the world to better understand and use our products. Second, they are in direct touch with Microsoft customers, being a great source of feedback for our team.

 

And we like to think we are important to the MVPs too! Direct access to Microsoft Product Team can be a plus in this concurred Information Era. MVPs have also easy access to Beta technologies and new features documentation, and are hosted here at Redmond Campus during the annual MVP Global Summit. This year we delivered first hand sessions on Microsoft Storage technologies, and discussed current and upcoming Storage features.

 

And how to become and MVP?

MVPs contribute with their knowledge and experience to the education of the Microsoft Community (in our case, File Services and Storage). So they can be found in Blogs, User Groups, Newsgroups, Forums, Technical Articles, and many other channels. They have great recognition for their technical expertise, and most important – they love sharing their knowledge with others. MVPs are as passionate by Microsoft technologies as they are for sharing this passion!

 

Meet the Storage Solutions MVPs:

File Services and Storage MVPs

Failover Clustering MVPs

Data Protection Manager MVPs

 

Learn more

Learn more about the award in the MVP Page.

Also visit the Microsoft MVPs blog.

You can use Storage Manager for SANs to create and manage logical unit numbers (LUNs) on both Fibre Channel and iSCSI disk storage subsystems that support Virtual Disk Service (VDS). The arrays are managed by the VDS hardware providers. The picture below illustrates how VDS communicates with the VDS hardware providers:

Storage Manager for SANs is one of the Management Applications as shown in the picture above. When Storage Manager for SANs launches, it queries the Virtual Disk Service for all the registered hardware providers. If there is no hardware providers presents on the system, Storage Manager for SANs will be disabled as it will not be able to offer any management functions.

Also, be sure about the physical connections between the server and the Array. If the logical layers are all present (indicated in the picture), but the physical layer is not connected, the communication will not be happen, and the application will be grayed out as well.

- Jane Yan

Webcast: Upcoming Changes to Data Protection Manager 2007 (Level 200); Wednesday, April 23, 2008; 8:00AM Pacific Time

Microsoft System Center Data Protection Manager 2007 delivers on the promises of blending continuous data protection and traditional tape backup for Microsoft workloads. This webcast answers the next question: What’s next for Data Protection Manager?

 

Brandon M. Baker

Our friends in the AskDS blog promised, and here it is:

 

The KB article on how to configure DFSR file-type compression in Windows Server 2008 is live!

 

On Windows Server 2003, there was a pre-defined list of file extensions that DFSR didn’t compress in the staging folder before replicating to other members in the replication group. The point is that, generally, there’s no gain in compressing already compressed files.

 

But what if you have other compressed files with different extensions? Well, in this case DFSR on Windows Server 2003 R2 tried to compress them – again.

 

In Windows Server 2008, you can add and remove file extensions from this list. If you have a file extension that you know is already compressed, or if you want for any reason to compress your zip files before replication, you can. How? Check the links below:

 

How to configure DFSR file-type compression in Windows Server 2008 - KB Article, 04/12/2008 (KB951003)

Customizing file compression in DFSR on Windows Server 2008 (no, not RDC) - AksDS Blog

 

--Malu Menezes

 

An ‘under the hood’ change on Windows Server 2008

 

A previous blog post mentioned some of the more end-user visible new features in Windows Server 2008. There is another less visible design enhancement on Windows Server 2008. Let us explore this change and find out how it can be beneficial to Server 2008 based deployments of the DFS Replication service.



Windows Server 2003 R2


On Windows Server 2003 R2, the staging area is contained within a folder under the replicated folder itself. Basically, there is a hidden sub-folder called ‘DfsrPrivate’ under the root of every replicated folder. This hidden folder contains private information stored by the DFS Replication service on a per-replicated folder basis. This private information includes the ‘ConflictAndDeleted’ directory, the ‘PreExisting’ directory and the ‘Staging Area’ for that replicated folder. The ‘PreExisting’ directory doesn’t exist on the Primary member in the replication group. An example of this behavior is illustrated in Figure 1, where the replicated folder ‘Reports’ has its Staging area, Conflicts and Deleted folder and Pre-Existing folder locations stored under the ‘DfsrPrivate’ subfolder. The size of these locations also contributes to the quota usage statistics for the replicated folder.
 

 

Figure 1: 'DfsrPrivate' folder on Windows Server 2003, R2.

However, this design doesn’t necessarily interoperate very well with some other applications that may be running on the file server. For instance, consider quota management applications. If the administrator sets a quota on the root of the replicated folder with a view of constraining the amount of space utilized by that folder/share, the space used by the contents of the ‘DfsrPrivate’ folder also end up getting counted towards that quota. Further, some quota management tools do not support excluding certain subfolders from the quota. The folders under ‘DfsrPrivate’ can end up growing reasonably large and consume large amounts of space. If the configured quota is hit, the quota management application starts returning disk full errors to the DFS Replication service. This adversely affects various aspects of replication including the staging process. Such eventualities could end up slowing down replication since there would need to be frequent staging area cleanups in order for the DFS Replication service to free up enough space to continue replication activities. Additionally, this behavior doesn’t constitute the most optimal quota consumption possible and end users might end up getting starved of quota.

 


Windows Server 2008


On Windows Server 2008, the ‘DfsrPrivate’ directory has been moved under the ‘System Volume Information’ folder on the same volume. In fact, all replicated folders hosted on that volume have their ‘DfsrPrivate’ folders at a consolidated location under the ‘
\System Volume Information\Dfsr\Private’ folder on the volume. The following folder structure can be found under the ‘System Volume Information’ folder:

‘\System Volume Information\Dfsr\Private\<Replicated Folder Id>-<Member Id>’


Here <Replicated Folder Id> and <Member Id> are essentially GUIDs which uniquely identify each replicated folder on that member server. Additionally, a directory junction point is created under the replicated folder root with the same old name ‘DfsrPrivate’ that now points to this new folder location under ‘System Volume Information’. The junction point also ensures that the DFS Management snap-in is able to work seamlessly while configuring both Windows Server 2003 R2 and Windows Server 2008 based DFS Replication servers. The snap-in thus still shows ‘Staging’ and ‘PreExisting’ folders to be subfolders of the ‘DfsrPrivate’ folder under the replicated folder root.

 

Figure 2: 'DfsrPrivate' junction point on Windows Server 2008.


This change ensures that the size of the files in ‘DfsrPrivate’ does not contribute to the quota usage statistics for the replicated folder.




Upgrade scenarios


When a server is upgraded from Windows Server 2003 R2 to Windows Server 2008, the DFS Replication service automatically moves the ‘DfsrPrivate’ folder under the ‘System Volume Information’ folder location on that volume and creates a directory junction point within the replicated folder root to point to this new location. Thus the DFS Replication service has consistent behavior with respect to the location of the ‘DfsrPrivate’ folder on both fresh installations of Windows Server 2008 and upgrades from Windows Server 2003 R2. If the administrator had previously specified a new location for the staging folder on Windows Server 2003 R2, then upon upgrade, staging will continue to use that custom location.

 

 

-------

Mahesh Unnikrishnan

 

 

Recently, the Failover Clustering team released several White Papers about High Availability and Clustering in Windows Server 2008:

 

§  Microsoft High Availability Overview

 

§  Overview of Failover Clustering with Windows Server 2008

 

§  Quick Migration with Hyper-V

 

§  Windows Server 2008 Failover Clustering Architecture Overview

 

§  Failover Clustering in Windows Server 2008 Enterprise Datasheet

 

§  Windows Server 2008 Multi-Site Clustering - Technical Decision-Maker White Paper

 

§  Windows Server 2008 - Product Page: High Availability  

 

For those seeking for that extra information, this is a great resource.

 

--Malu Menezes

Recently, Microsoft Support released an update for Windows Server 2003 SP2 that allows Chkdsk.exe tool compact the NTFS security descriptor stream (a.k.a. $secure file).

 

Depending on the file system usage, this descriptor can consume a lot of disk space. After getting to a certain size, no more security settings can be configured in NTFS. Those who attempted to compact this file before know it can be really tricky.

 

With this update, you can run Chkdsk.exe tool to compact $secure file by using the /f switch.

 

Check the instructions on how to download Chkdsk update here.

 

--Malu Menezes

The Storage Solutions Division Test Team is looking for several new Software Design Engineers in Test (SDET).

Interested? Visit http://members.microsoft.com/careers/default.mspx and search for Job Codes 202273, 206181, 207061, 208832, 210633, 212350, 217023, 217629, 217630, 217978, 219525 and 219528.

Where do you save your loved ones pictures, or your favorite tunes? Where does your company save all its payroll data? Or where does Hotmail store emails for all of its 380 million+ users?

Data storage has been at the core of all computer systems but the need for more robust storage solutions has never been greater than it is in today’s digital age. The Storage Solutions Division at Microsoft is committed to developing Simple, Scalable, Affordable and Flexible storage solutions for business users (small, medium or large) as well as home users. We hire the best of the industry, creating a challenging, yet exciting environment for personal growth while working to fundamentally change the software industry. Are you up for the challenge of complex operating system components and distributed storage systems?

At the Storage Solutions Division we develop the end-to-end experience for several critical storage scenarios. These scenarios include Storage Provisioning (local volume/disk management, SAN management, file share provisioning), Storage Resource Management (quotas and related policies), Shared Access Protocols (SMB, NFS, etc.), Distributed Storage (DFSN, DFSR), Offline Files (client side caching), iSCSI Target Configuration, etc. Together, the scenarios we own are critical for the multi-billion dollar Windows File Server business and also enable a number of other broader Windows client and server businesses. Owning the end-to-end scenario means that we develop multiple layers of the storage stack, from device drivers to system services to application programming interfaces to user interfaces for any given scenario. As a result we are able to ensure that our customers get a consistent experience whether they are developers building applications for the Windows platform or system administrators deploying and managing storage resources.

To develop and test solutions for all these valuable customer scenarios we need to work on the cutting edge of networking and storage technologies. Working here gives the opportunity to enhance ones knowledge about iSCSI, SAN, NAS, SMB, NFS, VDS, VSS and various other technologies. SDETs in our team serve as the customer’s advocate. They stay in tune with industry practices and customer needs by interacting with customers on various forums. They help with the design and development of features, develop test plans and automation strategies, write code to automate tests, track progress of test execution and provide a view of the quality of the product. They are constantly interacting with SDEs and PMs to iteratively fine tune the product features and corresponding tests.

Candidates should have the following basic qualifications.

 - At least 2 years programming C/C++ (academically or professionally).
 - Familiarity with C++/CLI, C#, .NET Framework, managed code, or SQL.
 - Minimum of a 4 year degree in computer science or a related field or equivalent experience.

Strong candidates will have experience, knowledge, and/or interests in the following areas.

 - Testing and test development
 - Operating systems fundamentals
 - File systems and storage technologies
 - Distributed systems and algorithms

 

- Amit Amit

 

 

SQL Server 2008 introduces new options to store unstructured data, in addition to the current BLOB support in SQL Server 2005.

In this post, I examine two previously existing options (IMAGE, VARBINARY(MAX)) and describe two new ones (VARBINARY(MAX) with FILESTREAM and RBS).

See the complete post at http://blogs.technet.com/josebda/archive/2008/03/17/sql-server-2008-and-unstructured-data.aspx.  

 

Jose Barreto

Some customers ask why parallel SCSI support was removed from Windows Server 2008.

 

Failover Cluster in Windows Server 2008 intents to achieve the highest standard of reliability. For that, every hardware component has to be marked as “certified for Windows Server 2008”, and pass all tests in the Failover Clustering Validation tool.  One of the conditions is that the SCSI device must support certain SPC-3 commands for the cluster service to work.  Parallel SCSI does not support some of these commands, so it was dropped from Failover Clustering in Windows Server 2008.  Furthermore virtually every major vender is deprecating production and support for parallel SCSI.

 

Windows Server 2008 Failover Clustering supports the following newer and more reliable shared bus types:

·         SAS – Serial Attached SCSI

·         iSCSI

·         Fibre Channel

 

Learn more about this in the article Parallel SCSI support in Windows Server 2008 Failover Clusters has been removed.

Find out What's New in Failover Clusters in Windows Server 2008.


Read the Failover and Network Balancing Clustering team blog.

The previous article in this series explained how to migrate replication of the SYSVOL share to the ‘REDIRECTED’ state. In this article, we examine how to complete migration of all domain controllers to the ‘ELIMINATED’ state.

 

Before we begin …

Remember that the migration process to the ‘ELIMINATED’ state cannot be reverted under any circumstances. Therefore, ensure that SYSVOL replication using the DFS Replication service is healthy, before committing entirely to finalizing the migration process.

Before migrating to the ‘ELIMINATED’ state, a couple of precautions are advised.

a)       All domain controllers are in ‘REDIRECTED’ state: The most important precaution is to ensure that all domain controllers have successfully migrated to the ‘REDIRECTED’ state before changing the global migration state to the ‘ELIMINATED’ state. As mentioned in the previous article, the command line switch ‘GetMigrationState’ can be used to ensure that all domain controllers have reached the ‘REDIRECTED’ state.

b)       Verify that the SYSVOL share is still being shared out: by all domain controllers and that the SYSVOL share path points to the path that is being replicated by the DFS Replication service (the ‘SYSVOL_DFSR’ folder location). This can be done by typing ‘net share’ on the domain controller. The SYSVOL share is listed if it is being shared out by that domain controller.


Migrating to ‘ELIMINATED’ state

Let’s look at how to migrate SYSVOL replication on the domain to the ‘ELIMINATED’ state. Please follow the below mentioned steps and pay special attention to any caution or warnings that are mentioned below.

ü  STEP 1: Check health of Active Directory Replication.

Since the migration directive is set on the Primary Domain Controller and needs to be replicated to the Active Directory on each of the replica domain controllers in the domain, it is necessary to ensure that Active Directory replication is working fine. This can be done using the ‘RepAdmin /ReplSum’ command. This step assumes importance in case of remote domain controllers, since those domain controllers will participate in SYSVOL migration only after noticing the migration directive, which in turn is dependent on Active Directory replication between the two sites.

 

ü  STEP 2: Set the migration directive.

On the Primary Domain Controller, run the dfsrmig.exe tool and set the migration global state to ‘ELIMINATED’ state (State 3). Issue the command ‘dfsrmig /setGlobalState 3’ on the Primary Domain Controller to commence migration to the ‘ELIMINATED’ state.

 

ü  STEP 3: Monitor to ensure that all domain controllers have reached the ‘ELIMINATED’ state successfully.

Use the ‘dfsrmig /getMigrationState’ command to ensure that all domain controllers have successfully migrated to the ‘ELIMINATED’ state. Ensure that the output for this command mentions that all domain controllers have reached the ‘ELIMINATED’ state.

When the DFS Replication service on each domain controller reaches the ‘ELIMINATED’ state, Information event 8019 will be registered in the event log.


What happens under the hood?

When the DFS Replication service notices the migration directive that has been set in Active Directory instructing it to migrate to the global migration state ‘ELIMINATED’, it performs the following sequence of operations on each domain controller:

a)       The migration local state is set to 7 (’ELIMINATING’).

b)       The DFS Replication service now performs the following set of actions on every domain controller:

·         The dependency between the NTDS service and the FRS service is now removed.

·         If the FRS service is running on the domain controller, it is then stopped. It deletes the Active Directory configuration settings required for the FRS service to replicate the SYSVOL share between domain controllers. Thus, all global settings of the FRS service that pertain to the SYSVOL content set are deleted.

·         The ‘SYSVOL’ folder which was being replicated by the FRS service is now deleted. Note that if you have Windows Explorer or the command shell open on the domain controller and if the current directory corresponds to the ‘SYSVOL’ folder location, the DFS Replication service will be unable to delete this folder owing to sharing violations.

·         If the FRS service is replicating any other content sets (apart from SYSVOL) on the domain controller, it is then started up again. 

c)       The migration local state is set to 3 (’ELIMINATED’). From this point onwards, the SYSVOL share advertised by the domain controller is the one that is replicated using the DFS Replication service. The FRS service no longer replicates any copy of the ‘SYSVOL’ folder on the domain controller.


During this migration process, the local migration state on the domain controller will cycle through the intermediate state of ‘ELIMINATING’ (State 7). All domain controllers undergo this procedure until they reach the ‘ELIMINATED’ migration state.

 

Can this migration step be rolled back?

No! At this point, the use of FRS on the domain controller for SYSVOL replication purposes has been eliminated.


 

Monitoring things closely

SYSVOL migration is designed to automatically recognize the migration directive and take steps on each domain controller to comply with that directive. Therefore, for the most part, the ‘/getMigrationState’ command should be sufficient to monitor the progress of migration to the ‘ELIMINATED’ state.

However, it is also possible for an administrator to monitor the domain controller closely and ensure that the tasks performed by the DFS Replication service while migrating to the ‘ELIMINATED’ state have been completed successfully. There are also some troubleshooting steps that can be performed to speed up Active Directory replication and Active Directory poll induced delays in the migration process.

a)       Verify the current local state on each domain controller. Navigate through the registry to the location ‘HKLM\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols’ and check to see the value of the registry key ‘LocalState’. Ensure this registry key is set to 3 once the domain controller has migrated to the ‘ELIMINATED’ state.

b)       Ensure that SYSVOL share replication has indeed been redirected. In order to ensure that the DFS Replication service is replicating the SYSVOL share that is shared out on the domain, check to see the values of the ‘SysVol’ and ‘SysvolReady’ registry keys mentioned above. Ensure that the ‘SysVol’ registry key is pointing to the ‘SYSVOL_DFSR’ folder location. Once the migration to the ‘ELIMINATED’ state is complete, ensure that the old copy of the ‘SYSVOL’ folder that was being replicated by FRS is deleted. 

c)        Force Active Directory replication on a domain controller. In order to force Active Directory replication, issue the command ‘repadmin /syncall /AeD on the domain controller.

d)       Force the DFS Replication service to poll Active Directory. In order to force an Active Directory poll, issue the command ‘dfsrdiag PollAd’ on the domain controller. To force an Active Directory poll on another domain controller issue the command ‘dfsrdiag PollAd /Member:DC_NAME’.

e)       If you find that migration is taking a long time to reach the ‘ELIMINATED’ state on a particular domain controller, the following set of monitoring steps may be taken:

·         Issue the ‘dfsrmig /getGlobalState’ command to find the global migration state and ensure that it is indeed set to ‘ELIMINATED’. If this command is issued on the domain controller that is taking a long time to migrate, the administrator can figure out whether Active Directory replication has completed replication of the migration directive to that domain controller.

·         Check to see the local migration state. The local state could take any of the values below during this migration step:

·         Local state 2 (‘REDIRECTED’ state)

·         Local state 7 (intermediate ‘ELIMINATING’ state)

·         Local state 3 (‘ELIMINATED’ state). This usually signifies that the domain controller has completed migration to the ‘ELIMINATED’ state.

·         Note that there are valid reasons for delay. Ensure that you are cognizant of these and have given enough time for these latencies to ‘play out’.

-          The migration directive relies on Active Directory replication to be ‘visible’ on each individual domain controller. Therefore, the speed with which each domain controller notices and acts upon the migration directive is dependen