Monday, November 30, 2015

Exchange 2010 - Restore from a "Recovery Database"

The restoration of a deleted item from a backup may be necessary when all other options have been exhausted. But before resorting to this option, we should ask ourselves:

  1. Can we simply recover the deleted item from the Deleted Items folder (the Outlook "Recycle Bin")?
  2. Can we recover the deleted item from the "Recover Deleted Items" folder (the Outlook "Dumpster")? Remember to highlight the folder from which the item was deleted when using this option.
  3. In the case of a disabled or removed mailbox (there is a slight but important difference), can we locate the mailbox in the "Disconnected Mailboxes" section of the Exchange Mailbox Console (EMC) and reconnect the mailbox to the associated Active Directory user account (or another user account)? Note that if we "removed" the mailbox, we will have deleted the associated Active Directory user account as well and would have to restore this object also.
Note: if the terms or concepts above are unfamiliar, please conduct an online search for clarification.


If we must restore a mailbox (or specific items) from backup, we can use a "Recovery Database". Previously, with Exchange 2007, this was known as a "Recovery Storage Group - RSG)" but since storage groups were eliminated from Exchange 2010 (and more recent versions), the name has changed. In this scenario, I will use Exchange 2010 (SP3 - RU10) but the procedure is very similar for Exchange 2013 (please see references at the end of this article - there is a link to the procedure for Exchange 2013).

The obvious pre-requisite is the availability of a recent backup. I created such a backup with the native Windows 2008 (R2) backup software which is now able to backup Exchange (this was not initially the case when Windows 2008 was released). The reader will have to make adjustments if using a 3rd party backup system such as Commvault or Veeam (etc.).


***

The recovery procedure can be divided into three major steps:
  1. Restore the Exchange database and logfiles to a specific location.
  2. Create (and then mount) the recovery database using these files.
  3. Perform the restore operations.
For step 3, it is essentially a matter of "copying" items from the recovery database (RDB) to the database where these items were originally located with the New-MailboxRestoreRequest cmdlet.



Restore the Exchange database and logfiles

I have created a folder named "A_RestoredFiles" on my C: drive. This is the location to which I will restore the Exchange database and transaction log files before creating (and then mounting) the RDB. Here is the restore procedure...

We open "Windows Server Backup" on the Exchange server. In the Action pane, select "Recover":





In our scenario (please see my previous blog post), we created the backup on a second hard drive. On the "Getting Started" page, we would therefore select "This server (EX13-1)":




We then select the backup we want to restore by date (and time):




Since Exchange is an application, we select the "Applications" option:




The server may have several applications but in our scenario there is only one. So we simply select Exchange:


Note: I opt not to check the roll-forward recovery option. This choice works for me (if you read what follows) but may or may not be suitable in other circumstances.



At this point, we can choose to recover to the original location or to another location. Since I want to create a separate Recovery Database using the restored files, I will select the second option and then designate the location where I want to restore the application:





We can simply click "Recover" on the confirmation screen:




And wait for the restore to complete:




The operation restores the database and log files based on their original location (file path):




Now that we have restored the database and transaction log files, we can use them to create the Recovery Database.




Create (and mount) the Recovery Database (RDB)

 When we restore the Exchange database and transaction log files to a new location, the database is usually in what is called a "Dirty Shutdown" state. We can verify this with the ESEUTIL command line tool (and we can also remedy this situation with the same tool).

First, we go to the location where the .edb file was restored and run the eseutil /mh command as shown here:

[PS] C:\>sl .\A_RestoredFiles
[PS] C:\A_RestoredFiles>sl .\C_
[PS] C:\A_RestoredFiles\C_>sl .\A-DB1
[PS] C:\A_RestoredFiles\C_\A-DB1>eseutil /mh db1.edb

Note: the Exchange database exists in a file with the .edb extension.

Note: "sl" is the abbreviation of the Powershell cmdlet "Set-Location". Similar to the traditional "cd" command, it allows us to move around the file structure at the command line.


This is probably the result that you would obtain in comparable circumstances:

[...]
State: Dirty Shutdown
Log Required: 386-388 (0x182-0x184)
Log Committed: 0-389 (0x0-0x185)
[...]

Note: the output of the eseutil /mh command is quite abundant so I have cut all but the most relevant parts above.

But why is this important?

Because a database will not mount when it is in a "Dirty Shutdown"state.

We can change the shutdown state with the eseutil /r command but eseutil needs to know the location of the transaction log files. We can either designate the location of these files or copy them to the location of the database file (eseutil looks for the log files in this location by default). I will opt for the second option...

Copy...




Paste...




Note the respective path of the database file and the log files.



We now repair the database with the ESEUTIL /R command:

[PS] C:\A_RestoredFiles\C_\A-DB1>eseutil /r E01 /i /d

[...]

Initiating RECOVERY mode...
    Logfile base name: E01
    Log files: <current directory>
    System files: <current directory>
   Database Directory: <current directory>

Performing soft recovery...
                      Restore Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ...................................................

Operation completed successfully in 4.212 seconds.



Now we can see that the database is in a clean shutdown state and can be mounted:

[PS] C:\A_RestoredFiles\C_\A-DB1>eseutil /mh db1.edb

[...]

State: Clean Shutdown
Log Required: 0-0 (0x0-0x0)
Log Committed: 0-0 (0x0-0x0)
Log Recovering: 0 (0x0)

[...]


At this point, we need to clarify the status of the DB1.edb file we restored and repaired with ESEUTIL (so it would be in a "Clean Shutdown" state). This file is the restored database but Exchange is not aware of the existence of this file and does not recognize it as a "mailbox database". We can observe this for ourselves with the Get-MailboxDatabase cmdlet:

[PS] C:\>Get-MailboxDatabase

Name                    Server          Recovery        ReplicationType
----                           ------          --------        ---------------
DB1                      EX13-1          False           Remote

Exchange only sees the original copy of the database and not the restored file that we want to use as the Recovery Database.

Therefore, we need to create a new "Mailbox Database" with the restored file and specify that it is a "Recovery" database. We can accomplish that with the following command:

[PS] C:\>New-MailboxDatabase -Recovery -Server EX13-1 -Name RDB1 -EdbFilePath "C:\A_RestoredFiles\C_\A-DB1\DB1.edb" -LogFolderPath "C:\A_RestoredFiles\C_\A-DB1"

Note: the "-Recovery" parameter makes this mailbox database a recovery database (RDB).


We may see the following warning stating that the database must be brought into a clean shutdown state before it can be mounted. In our case, we have already accomplished this task and can disregard the warning:

WARNING: Recovery database 'RDB1' was created using existing file C:\A_RestoredFiles\C_\A-DB1\DB1.edb. The database must be brought into a clean shutdown state before it can be mounted.

Now "RDB1" is recognized as a (recovery) mailbox database.

[PS] C:\>Get-MailboxDatabase

Name                   Server          Recovery    ReplicationType
----                         ------            --------        ---------------
DB1                      EX13-1          False           Remote
RDB1                   EX13-1          True            None


This is what we see in the Exchange Management Console (EMC):



All we have to do next is mount the database:

[PS] C:\>Mount-Database RDB1


If we want to see what mailboxes are in the database, we can use the Get-MailboxStatistics cmdlet. The Get-Mailbox cmdlet does not seem to produce output with a RDB:

[PS] C:\>Get-Mailbox -Database RDB1
[PS] C:\>Get-MailboxStatistics -Database RDB1 | fl DisplayName

DisplayName : Aisha Bhari
DisplayName : Alex Heyne



Restore mailbox items from the RDB to the source database

Since Exchange 2010 SP1, the New-MailboxRestoreRequest cmdlet enables us to restore items from the RDB to the source database . This cmdlet replaces the former Restore-Mailbox cmdlet (now deprecated).

I intend to illustrate some of the possible restore options by presenting the status quo of the user mailbox of Alex Heyne (test user) when the backup mentioned above was taken and just before I deleted the items shown below (not only from the original folder locations but also from the recycle bin and the "dumpster").

Then I will show what his mailbox looks like once the items are restored.

So, when the backup was taken, there were 3 messages in Alex Heyne's Inbox and 3 messages in his Sent Items folder:






Once again, all these messages were deleted after the backup was taken: from the Inbox and Sent Items folder but also the Recycle Bin and "Dumpster".

Of course, it is only later that we realize these messages should have been retained!

How can we retrieve them?

The New-MailboxRestoreRequest with the following parameters restores the messages the their original location:

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Alex Heyne" -TargetMailbox "Alex Heyne"

I will not post additional screenshots here because you would simply see what you see above: essentially a return to the "status quo ante" or "situation as it was before".

Note: since all the messages were deleted there were no conflicts. But what if the backup included items that were not deleted? What would happen then? Default behavior is to keep the source item or in other words overwrite the item still present in the target database. There are parameters that change this default behavior. Please consult the references at the end of this post and in particular (for this subject) the article by Paul Cunningham.


This combination of parameters restores the entire mailbox to a single folder named "Restored Files" (in my example):

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Alex Heyne" -TargetMailbox "Alex Heyne" -TargetRootFolder "Restored Items"

And this is what the user would see in Outlook:


The entire folder structure, including the normally hidden "Recoverable Items" folder, is restored to the designated "TargetRootFolder" as well as the content of the folders (Sent Items are shown above).

Note: I have performed the restore operation with Outlook open and in that case, the items usually appear instantly with no user interaction. In the example above, however, it was necessary to close and reopen Outlook. Try this before concluding that the restore operation failed.


This combination of parameters restores only the Inbox to a single folder name "Restored Files":

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Alex Heyne" -TargetMailbox "Alex Heyne" -TargetRootFolder "Restored Items" -IncludeFolders "#Inbox#"


Note: the "Recoverable Items" folder is still restored. We can avoid this by adding the following parameter:

-ExcludeDumpster


One more example: the following combination allows us to restore Alex Heyne's entire mailbox to the specified folder inside of Alan Reid's mailbox:

New-MailboxRestoreRequest -SourceDatabase RDB1 -SourceStoreMailbox "Alex Heyne" -TargetMailbox "Alan Reid" -TargetRootFolder "Restored Items" -AllowLegacyDNMismatch



This could be useful if the user is no longer with the organization and someone has been designated to recover some important items (pertaining to a contract, for example) from a backup of the former employee's mailbox.

The "AllowLegacyDNMismatch" parameter is mandatory if we want to restore the mailbox into another user's mailbox like in the example above. By default, Exchange will not allow this. We have to specify explicitly that this is our intention. Otherwise, we will see the following error:

Source mailbox's legacyExchangeDN '/O=MYNET/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=ALEX.HEYNE' doesn't match [...].


The restore request may require some time to finish. We can check the status of the request(s) with this cmdlet:

Get-MailboxRestoreRequest


After the restore is complete, we can remove the restore requests with this combination of cmdlets:

Get-MailboxRestoreRequest | Remove-MailboxRestoreRequest


Furthermore, there is no need to keep the Recovery Database permanently, so we would want to dismount it and then remove it with the following cmdlets:

Dismount-Database RDB1

Remove-MailboxDatabase RDB1

After we execute the cmdlet above, we should see a warning like this: 

WARNING: The specified database has been removed. You must remove the database file located in... C:\RestoredFiles\C_\A-DB1\DB1.edb from your computer manually if it exists. Specified database: RDB1

It is simply a matter of deleting the files in question from either File Explorer or the command line.





References:

Technet reference:



Article by Exchange MVP Mike Pfeiffer:



Article by Exchange MVP Paul Cunningham:


Saturday, November 28, 2015

Exchange 2010 - Native Windows backup of Exchange

This is a short blog post that presents the backup of an Exchange 2010 (SP3 - RU10) server using native Windows backup. It is meant to be informational in itself but also fulfills a preliminary requisite for the following blog post in which I will demonstrate how to restore mailbox items using what is called a "Recovery Database" or "RDB"). Indeed, we cannot perform a restore without a backup to begin with.

***

First, we go to "Administrative Tools" and select "Windows Server Backup". This is a Windows Server  "feature" (as opposed to a "role"). If the "WSB" feature has not been added, an error message will display. We can overcome this obstacle by installing the feature.


For this exercise, we will click on the "Backup Once" option in the Action pane:




Then "Different options":




I will select "Custom" for the backup configuration. This allows me to see exactly what elements I will backup:




On the "Select Items for Backup" page, we have to click on the "Add Items" button:





We will select all the boxes except "Backup (B)". This is an additional hard drive that we will use to store the backup:





We click "OK" and return to the configuration page. We then click on "Advanced Settings" and then the "VSS Settings" tab. I will select the "VSS full Backup" option since I am not using another product (other than Windows native backup) for the backup:




For this exercise, I will use a local drive (a shared folder on the network is the other option):




We then select the specific volume itself:




I confirm the settings selected (and click OK):




I can observe the progress of the backup during the execution of the backup job:




If all goes well, status for all backup operations should read "Completed".




***


In reality, we would probably want to schedule a backup to occur at regular intervals, targeting, perhaps, a remote shared folder elsewhere on the network.

In any case, we now have a "full server backup" which includes, besides the Windows OS, the Exchange system files, databases and log files (some of which have been truncated during the backup operation). We will use this backup in my next blog post to create a "Recovery Database" from which we can (essentially) copy items from the "RDB" to the database where the items existed before they were deleted.

Sunday, November 22, 2015

Exchange 2010 - ESEUTIL - ISINTEG - New-MailboxRepairRequest

For several generations of Exchange, we could verify the health of the information store with a combination of the tools known as ESEUTIL and ISINTEG.

ESEUTIL still exists - but with very limited value. The reader will see how limited in the lines below. It can even de dangerous.

ISINTEG, on the other hand, is no longer an option since Exchange 2010 SP1 and has been replaced by the New-MailboxRepairRequest cmdlet.

I'll present both of these tools successively in the lines below.

With words of warning...




ESEUTIL

ESEUTIL is able to perform various operations on a dismounted Exchange mailbox database. Here is the list:

C:\>eseutil

[...]

MODES OF OPERATION:

Defragmentation:  ESEUTIL /d <database name> [options]
Recovery:  ESEUTIL /r <logfile base name> [options]
Integrity:  ESEUTIL /g <database name> [options]
Checksum:  ESEUTIL /k <file name> [options]
Repair:  ESEUTIL /p <database name> [options]
File Dump:  ESEUTIL /m[mode-modifier] <filename>
Copy File:  ESEUTIL /y <source file> [options]
Restore:  ESEUTIL /c[mode-modifier] <path name> [options]


Exchange performs "online" defragmentation of the mailbox databases automatically as a background process. Online defragmentation, however, does not recuperate what is known as "white space". This is free space resulting from (for example) the deletion of a former employee's mailbox. Exchange can use this free space but Exchange does not reduce the size of the mailbox database on disk. If we have a 10 GB database and the former employee was using 5 GB of this space, the size of the database remains 10 GB on disk (even though there are now 5 GB available inside the database). In other words, the size of the database (as a file) does not shrink when we delete (internal) content.

Quite often, on the Exchange TechNet forums, someone will ask about the ESEUTIL /d option because they want to reduce the size of the Exchange database in the file system.

On this subject, we need to keep a number of things in mind.

ESEUTIL /d performs an "offline defragmentation" of the Exhange mailbox database. The mailbox database must be dismounted ("offline") and mailboxes will not be available. Downtime must be scheduled.

Offline defragmentation requires additional free disk space, roughly equivalent to the size of the database being defragmented.

Indeed, the defragmentation of an Exchange mailbox database is not like the defragmentation of a hard drive volume.

When we defragment an Exchange database, we create, in fact, a new database and copy the content of the old database into the new database. Therefore, if we have a 100GB mailbox database, we need at least 100GB of free space somewhere to defragment.

The preferred option is simply to move mailboxes to a new database.

Moreover, if we have Exchagne 2010 (or above) and if we implement a DAG (Database Availability Group) we must NOT perform an offline defragmentation of any mailbox databases:

Offline Defrag And DAG Databases, Oh My!

Should You Defrag Exchange Server Mailbox Databases?


Concerning the ESEUTIL /P and /R options, I will simply note that while they might be useful last resort options, there is a risk of data loss. If ESEUTIL cannot find all the log files, it will skip them and the associated data will be lost. I have often seen the recommendation that one consult Microsoft before executing these commands.

So the value of ESEUTIL has greatly diminished since Exchange 2010. For some Exchange experts, it is even considered... "evil":

ESEUTIL is now the evil utility


What about ESEUTIL /g ?

We can use it but it works only on dismounted databases. This means downtime - potentially a lot of downtime if the database is very large. Some would argue that, if we are having problems with the database, we should just move mailboxes to another database:

Using eseutil in a DAG - Which databases do you scan?


Otherwise, ESEUTIL /G is a read-only operation and should be safe for the database.

Note: yes, these commands are case insensitive. We can write "g" or "G".

Perhaps the only reason to use ESEUTIL would be to view information about the database which we can obtain with variations of the /M switch. 




New-MailboxRepairRequest

Microsoft documentation explains that it can "detect and repair" mailbox corruption.

Create a Mailbox Repair Request

This command has one major advantage over ISINTEG (besides the fact that ISTINTEG is not even an option anymore): it can be run on mounted databases. In fact, it MUST be run against a mounted database or we will have an EventID 10051 error.

The command can be used on a single mailbox or an entire mailbox database. Even so, it runs against a single mailbox at a time so only the mailbox being checked will be affected. The documentation mentions access being "disrupted".

We can detect four types of problems using one, all, or a combination of the following values for the parameter "CorruptionType":

- SearchFolder
- AggregateCounts
- ProvisionedFolder
- FolderView


Please see the following TechNet article for more details:


Here are some examples of the various uses of the command...


This command detects all forms of corruption in the mailbox of user Alex Heyne: 

New-MailboxRepairRequest -Mailbox Alex.Heyne -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView -DetectOnly


We must list all the tests we want to perform. If we only want to perform one type of test, we simply do not list the others:

New-MailboxRepairRequest -Mailbox Alex.Heyne -CorruptionType ProvisionedFolder -DetectOnly


If we want to repair the corruption, we omit the -DetectOnly parameter:

New-MailboxRepairRequest -Mailbox Alex.Heyne -CorruptionType ProvisionedFolder


If we want to check (and repair) an entire mailbox database (for all forms of corruption), we use this command:

New-MailboxRepairRequest -Database DB1 -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView


How can we view the status of the check?

For Exchange 2010, there is no Get-MailboxRepairRequest cmdlet allowing us to view what percent of the operation is complete.

Note: this command does exist in Exchange 2016 however:

Get-MailboxRepairRequest




We have to examine the Event Viewer logs, in particular the Event ID 10047 and 10048. These entries indicate that the check started and then completed successfully.





Of course, in case of corruption there would be another Event ID in the Event Viewer. For a list of possible entries, please consult this link:

View Mailbox Repair Request Entries in Event Viewer


We should also note that in the case of a mailbox, the entry in the Event Viewer does not refer to the mailbox scanned for corruption by its name but rather by a GUID called "Exchange GUID".

We can find the ExchangeGUID of a mailbox with this command:

[PS] C:\>Get-Mailbox Alex.Heyne | fl *ExchangeGUID*

ExchangeGuid : 7e51bb21-5100-4bbd-a493-4654eb24dcfd

Saturday, November 21, 2015

FR (French) - REPADMIN - Active Directory replication commands - Part 2

English abstract: in the following paragraphs, I'll add some more comments on Active Directory replication and introduce some more REPADMIN commands.

Dans les paragraphes suivants, je vais faire d'autres remarques sur la réplication Active Directory et présenter encore quelques commandes REPADMIN.

***

Au sein d'un même site, la réplication entre contrôleurs de domaine se fait presque en temps réel : au départ toutes les 15 secondes et ensuite les contrôleurs de domaine (désormais abrégé en "DC") mettent leurs partenaires de réplication au courant de tout changement toutes les trois secondes.

Il faut bien comprendre que, même si le DC "A" avertit le DC "B" qu'un changement vient de se faire, c'est toujours (dans ce cas) le DC "B" qui "tire" les données vers lui depuis le DC "A". En version anglaise originale, c'est la différence entre PULL et PUSH.

De plus, certains changements font l'objet d'une "réplication urgente" :
  • Verrouillage de compte
  • Changement de stratégie de verrouillage de compte ou de stratégie de mot de passe.
  • Changement de mot de passe d'un contrôleur de domaine (oui, les ordinateurs ont aussi un mot de passe).

Dans ces cas, la réplication n'attend pas 15 secondes mais se fait immédiatement.

***

Concernant le GUID de l'objet DSA et l'ID de l'Invocation, ils sont les mêmes au premier contrôleur de domaine de la forêt.

Voici un exemple pris d'un autre réseau d'essai avec un seul DC :

C:\>repadmin /showrepl

Repadmin: running command /showrepl against full DC localhost
Default-First-Site-Name\DC10
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 573bb700-73c0-4510-bb1e-027338b567f1
DSA invocationID: 573bb700-73c0-4510-bb1e-027338b567f1



repadmin /showutdvec

Si nous voulons voir si deux contrôleurs de domaine sont synchronisés l'un avec l'autre, nous pouvons exécuter cette commande et comparer...

  • l'USN (Update Sequence Number) le plus élevé de DC3 (dans notre exemple)
  • Ce que DC4 croit être l'USN le plus élevé de DC3.

En fait, il semble qu'il y ait toujours quelque chose qui fait l'objet d'une réplication et il n'est pas toujours facile, même après avoir forcé une réplication manuelle, d'en arriver à des USN identiques partout.

Dans l'exemple ci-dessous, DC4 croit que l'USN le plus élévé de DC3 est 41115 et DC3 le confirme : 41115 = 41115

Par contre, DC4 croit que son USN le plus élévé est 37075 alors que DC3 croit que c'est toujours 37060.

Je force la réplication, l'USN pour DC3 change mais reste identique aux deux contrôleurs de domaine. L'USN pour DC4 change aussi mais c'est un numéro différent:


C:\>repadmin /showutdvec DC4 dc=machlinkit,dc=biz
Mise en cache des GUID.
..
Site-1\DC3                           @ USN     41115 @ Heure 2015-11-14 15:58:40
Site-1\DC4                           @ USN     37075 @ Heure 2015-11-14 15:59:58


C:\>repadmin /showutdvec DC3 dc=machlinkit,dc=biz
Mise en cache des GUID.
..
Site-1\DC3                           @ USN     41115 @ Heure 2015-11-14 16:00:05
Site-1\DC4                           @ USN     37060 @ Heure 2015-11-14 15:58:37


C:\>repadmin /replicate DC3 DC4 dc=machlinkit,dc=biz
La synchronisation entre DC4 et DC3 a réussi.

C:\>repadmin /replicate DC4 DC3 dc=machlinkit,dc=biz
La synchronisation entre DC3 et DC4 a réussi.


C:\>repadmin /showutdvec DC3 dc=machlinkit,dc=biz
Mise en cache des GUID.
..
Site-1\DC3                           @ USN     41119 @ Heure 2015-11-14 16:03:23
Site-1\DC4                           @ USN     37075 @ Heure 2015-11-14 16:03:11


C:\>repadmin /showutdvec DC4 dc=machlinkit,dc=biz
Mise en cache des GUID.
..
Site-1\DC3                           @ USN     41119 @ Heure 2015-11-14 16:03:25
Site-1\DC4                           @ USN     37081 @ Heure 2015-11-14 16:03:33





repadmin /showchanges

Les commandes ci-dessous sont censées montrer les différences entre deux contrôleurs de domaine. Dans mon cas, et même avec seulement deux partenaires (et après une réplication bidirectionnelle manuelle), le rendu était pléthorique.

C:\>repadmin /showchanges DC3 dc=machlinkit,dc=biz
C:\>repadmin /showchanges DC4 dc=machlinkit,dc=biz

Ajouter le paramètre /statistics en offre un affichage un peu moins abondant.




repadmin /showsig

La commande repadmin /showrepl nous montre de nombreux détails sur les partenaires de réplication dont l'ID de l'Invocation DSA (Invocation ID). Si nous ne voulons voir que cela, nous pouvons exécuter la commande suivante :

C:\>repadmin /showsig

Repadmin : exécution de la commande /showsig sur le contrôleur de domaine complet localhost
Site-1\DC4

Actuel : ID de l'invocation DSA : d6e3c414-ab12-4d71-a3bc-135aba5ac84c

Aucune signature retirée.

Wednesday, November 11, 2015

FR (French) - REPADMIN - Active Directory replication commands - Part 1

English abstract: I present some basic aspects of Active Directory replication as well as REPADMIN commands to view replication status or force manual replication between domain controllers.

Active Directory stocke les objets du domaine (utilisateurs, groupes, ordinateurs, et autres éléments) dans une base de données dont une copie se trouve à chaque contrôleur de domaine (désormais abrégé en "DC"). Chaque fois qu'on ajoute un nouveau DC au domaine, le contenu de cette base de données doit être copié vers la base de données du nouveau DC. En outre, chaque fois qu'on change un objet (création, modification des propriétés, suppression) à un DC particulier, le changement en question doit se reproduire dans la copie de la base de données qui se trouve aux autres DCs.


***


Précisons le vocabulaire de ce processus...

La copie de la base de donnée s'appelle "replica". On pourrait traduire ce mot par "copie exacte". Dans le lexique technique, on écrit simplement "réplique".

Le verbe  "replicate" désigne l'action de "reproduire" les changements effectués dans une copie de la base de données dans les autres copies de la base de données.

Le nom "replication" se traduit en général par "reproduction" mais encore une fois, nous verrons simplement "réplication" dans la documentation technique française.


***


L'outil REPADMIN (ou repadmin) permet de voir l'état de la réplication et aussi de déclencher le processus de façon manuelle au besoin. C'est le sujet de cet article.

Avant de présenter les commandes "repadmin" elles-mêmes (il s'agit d'un outil de ligne de commande), je crois utile d'expliquer comment la base de données Active Directory se ségmente en parties distinctes, et propres à faire l'objet d'une réplication indépendante des autres.

La base de donnée Active Directory existe sous la forme d'un fichier nommé NTDS.DIT, associé, en fait, à d'autres fichiers que je ne présenterai pas ici. En effet, je veux me concentrer sur l'outil "repadmin" et ne pas faire une présentation globale d'Active Directory. En outre, je vais supposer, chez le lecteur, une assez bonne connaissance d'Active Directory. Dans le cas contraire, je l'inviterais à consulter d'autres sources pour se mettre à jour.

Je voulais donc préciser que la base de données se divise en partitions qu'on appelle aussi des contextes de nommage (naming contexts - NC):

1 - Domain NC : DC=machlinkit,DC=biz
2 - Configuration NC : CN=Configuration,DC=machlinkit,DC=biz
3 - Schema NC : CN=Schema,CN=Configuration,DC=machlinkit,DC=biz
4 - DNS Application partition (domain) : DC=DomainDnsZones,DC=machlinkit,DC=biz
5 - DNS Application partition (forest) : DC=ForestDnsZones,DC=machlinkit,DC=biz


Voici une description sommaire de chacune de ces partitions:
  1. La partition de domaine contient tous les objets comme les utilisateurs, groupes, ordinateurs.
  2. La partition d'entreprise contient des données sur les sites et les services, notamment sur le système de messagerie Exchange (s'il est présent).
  3. La partition de schéma contient des modèles pour les objets, définissant les types d'objets qui peuvent exister dans le domaine ainsi que les propriétés de ces objets.
  4. Cette parition existe si DNS est intégré à Active Directory et les enregistrements DNS qu'elle contient sont répliqués à l'étendue du domaine.
  5. Cette parition existe si DNS est intégré à Active Directory et les enregistrements DNS qu'elle contient sont répliqués à l'étendue de la forêt.


Ces précisions faites, je vais passer à la présentation des commandes "repadmin" que je trouve les plus utiles. Pour des renseignements encore plus complets, je renvoie le lecteur à la documentation Microsoft à ce sujet, soit en anglais, soit en français. Une simple recherche pour "repadmin" devrait donner des liens aux articles Microsoft officiels.

Note: mon réseau d'essai ne compte que 2 DC ("DC3" et "DC4") de sorte que l'affichage est assez simple. L'affichage des résultats dans un domaine avec d'autres DCs serait plus complexe.



repadmin /replsum

Cette commande affiche, le cas échéant, le nombre d'échecs de réplication. Dans l'exemple ci-dessous, aucun échec n'a été enregistré. Les colonnes ne s'alignent pas tout à fait dans l'interface française. Si on s'en rapporte à l'interface anglaise d'origine, nous devrions lire "nombre d'échecs" (0), "nombre total de partitions répliquées" (5) et "pourcentage d'erreur" (0). Obtenir de tels résultats est bon signe.


C:\>repadmin /replsum
Heure de début du résumé de la réplication : 2015-11-07 19:57:36

Début de la collecte des données pour le résumé de la réplication ;
cette opération peut prendre un certain temps :
  .....
DSA source             différence max    nb échecs %%   erreur
 DC3                       06m:42s    0 /   5    0
 DC4                       06m:45s    0 /   5    0

DSA de destination     différence max    nb échecs %%   erreur
 DC3                       06m:45s    0 /   5    0
 DC4                       06m:42s    0 /   5    0





repamin /showrepl

Cette commande fournit des détails plus spécifiques sur le DC et ses partitions:


C:\>repadmin /showrepl

Repadmin : exécution de la commande /showrepl sur le contrôleur de domaine complet localhost
Default-First-Site-Name\DC4
Options DSA : IS_GC
Options de site : (none)
GUID de l'objet DSA : 58d00eef-a083-47a5-9cf7-d854ac13bf79
ID de l'invocation DSA : d6e3c414-ab12-4d71-a3bc-135aba5ac84c

=== INSTANCES VOISINES ENTRANTES ==================================

DC=machlinkit,DC=biz
    Default-First-Site-Name\DC3 via RPC
        GUID de l'objet DSA : 75a4a675-5ee2-40c6-b693-718d57461eeb
        La dernière tentative, le 2015-11-07 19:58:23, a réussi.

DC=machlinkit,DC=biz
    Default-First-Site-Name\DC3 via RPC
        GUID de l'objet DSA : 75a4a675-5ee2-40c6-b693-718d57461eeb
        La dernière tentative, le 2015-11-07 19:50:54, a réussi.

CN=Schema,CN=Configuration,DC=machlinkit,DC=biz
    Default-First-Site-Name\DC3 via RPC
        GUID de l'objet DSA : 75a4a675-5ee2-40c6-b693-718d57461eeb
        La dernière tentative, le 2015-11-07 19:50:54, a réussi.

DC=DomainDnsZones,DC=machlinkit,DC=biz
    Default-First-Site-Name\DC3 via RPC
        GUID de l'objet DSA : 75a4a675-5ee2-40c6-b693-718d57461eeb
        La dernière tentative, le 2015-11-07 19:50:54, a réussi.

DC=ForestDnsZones,DC=machlinkit,DC=biz
    Default-First-Site-Name\DC3 via RPC
        GUID de l'objet DSA : 75a4a675-5ee2-40c6-b693-718d57461eeb
        La dernière tentative, le 2015-11-07 19:50:54, a réussi.



Que veut dire tout cela ?

Nous apprenons que le DC est aussi un catalogue global (Options DSA : IS_GC).

Le "GUID de l'objet DSA" est celui du contrôleur de domaine lui-même et permet son identification parmi les autres DCs, et cela même si le DC est renommé. Rien ne changera ce GUID, même pas une restauration de la base de données Active Directory au DC en question.

"ID de l'invocation DSA" identifie la copie de la base de données Active Directory de ce DC. Chaque copie de la base de données a le sien propre. A la différence du GUID de l'objet DSA (pour le DC), l'ID de la base de données change en cas de restauration de la base de données.


Pour résumer (avec les termes anglais originaux):

- DSA object GUID -> le contrôleur de domaine (DC)
- DSA invocationID -> la base de données


Note : pour être tout à fait précis, le GUID de l'objet DSA identifie l'objet "NTDS Settings" du contrôleur de domaine :

CN=NTDS Settings,CN=DC3,CN=Servers,CN=Site-1,CN=Sites,CN=Configuration, DC=machlinkit,DC=biz


Ensuite, nous voyons affiché l'état de la réplication de chacune des cinq partitions (ou contextes de nommage) présentées plus haut.

Pour chaque partition, nous voyons le site du contrôleur de domaine partenaire (un seul dans mon réseau d'essai), le GUID de ce DC et finalement l'heure et le résultat de la dernière réplication.

Note : il convient de garder ces faits à l'esprit :
  1. Seuls les changements réalisés depuis la dernière réplication font l'objet de la réplication en cours. Les données déjà reproduites dans les autres bases de données ne font pas l'objet d'une nouvelle réplication - ou d'une réplication continuelle.
  2. Seuls les attributs (ou propriétés) des objets modifiés font l'objet d'une réplication et non pas tout l'objet (sauf au moment de sa création). Cela évite de recopier tout l'objet vers les autres DC quand seulement un simple détail vient de changer (un chiffre du numéro de téléphone par exemple).
  3. Par défaut, chaque DC tire vers lui les changements à reproduire dans sa copie de la base de données, depuis les autres DCs, au lieu de pousser les changements effectués localement vers ces DCs. En anglais, c'est l'opposition entre PULL et PUSH (tirer vers soi au lieu de pousser vers les autres). Il pourrait être utile de garder cette distinction à l'esprit quand nous verrons les commandes pour forcer une réplication manuelle entre DCs. 



repadmin /replicate

Cette commande force la réplication entre la source (DC4 dans mon exemple) et la destination (DC3).

Tenez bien compte de la syntaxe :

repadmin /replicate DestDC SrcDC NC

Ou bien...

repadmin /replicate DC_Destination DC_Source Naming_Context

Et Tenez bien compte du sens de la réplication :

DC3 <- DC4


Cela donne ce qui suit pour les cinq partitions que nous avons présentées plus haut :

C:\>repadmin /replicate DC3 DC4 dc=machlinkit,dc=biz
La synchronisation entre DC4 et DC3 a réussi.

C:\>repadmin /replicate DC3 DC4 cn=configuration,dc=machlinkit,dc=biz
La synchronisation entre DC4 et DC3 a réussi.

C:\>repadmin /replicate DC3 DC4 cn=schema,cn=configuration,dc=machlinkit,dc=biz
La synchronisation entre DC4 et DC3 a réussi.

C:\>repadmin /replicate DC3 DC4 dc=DomainDNSZones,dc=machlinkit,dc=biz
La synchronisation entre DC4 et DC3 a réussi.

C:\>repadmin /replicate DC3 DC4 dc=ForestDNSZones,dc=machlinkit,dc=biz
La synchronisation entre DC4 et DC3 a réussi.


Quelques remarques...

  • Nous pouvons mettre le FQDN du DC, DC3.machlinkit.biz, ou simplement DC3.
  • Nous pouvons mettre "dc" ou "DC" ainsi que "cn" ou "CN".


Pour forcer la réplication dans l'autre sens, nous inversons simplement la position des DCs dans la commande, par exemple :

C:\>repadmin /replicate DC4 DC3 dc=machlinkit,dc=biz




repamin /syncall

Cette commande déclenche la réplication entre le DC spécifié et tous les partenaires de ce DC. Encore une fois, le DC "tire" les données à répliquer vers lui-même à partir de ses partenaires.

Il faut préciser aussi la partition (ou contexte de nommage - naming context).

Dans mon réseau, nous n'avons que 2 contrôleurs de domaine, ce qui fait que le résultat obtenu est le même qu'en utilisant le paramètre /replicate.


Voici quelques exemples :

C:\>repadmin /syncall DC4 dc=machlinkit,dc=biz
Synchronisation de la partition : dc=machlinkit,dc=biz
MESSAGE DE RAPPEL : La réplication suivante est en cours :
    À partir de : 75a4a675-5ee2-40c6-b693-718d57461eeb._msdcs.machlinkit.biz
    Vers....... : 58d00eef-a083-47a5-9cf7-d854ac13bf79._msdcs.machlinkit.biz
MESSAGE DE RAPPEL : La réplication suivante s'est terminée correctement :
    À partir de : 75a4a675-5ee2-40c6-b693-718d57461eeb._msdcs.machlinkit.biz
    Vers....... : 58d00eef-a083-47a5-9cf7-d854ac13bf79._msdcs.machlinkit.biz
MESSAGE DE RAPPEL : Synchronisation totale terminée.
Synchronisation totale effectuée sans erreur.


C:\>repadmin /syncall DC4 cn=configuration,dc=machlinkit,dc=biz
Synchronisation de la partition : cn=configuration,dc=machlinkit,dc=biz
MESSAGE DE RAPPEL : La réplication suivante est en cours :
    À partir de : 75a4a675-5ee2-40c6-b693-718d57461eeb._msdcs.machlinkit.biz
    Vers....... : 58d00eef-a083-47a5-9cf7-d854ac13bf79._msdcs.machlinkit.biz
MESSAGE DE RAPPEL : La réplication suivante s'est terminée correctement :
    À partir de : 75a4a675-5ee2-40c6-b693-718d57461eeb._msdcs.machlinkit.biz
    Vers....... : 58d00eef-a083-47a5-9cf7-d854ac13bf79._msdcs.machlinkit.biz
MESSAGE DE RAPPEL : Synchronisation totale terminée.
Synchronisation totale effectuée sans erreur.



  • "75a4a675-5ee2-40c6-b693-718d57461eeb" est le "DSA Object GUID" de DC3, le partenaire de réplication de DC4.
  • "58d00eef-a083-47a5-9cf7-d854ac13bf79" est le "DSA Object GUID" de DC4 lui-même (le DC auquel nous nous trouvons).



Ces GUIDs de l'objet DSA existent aussi sous la forme d'un enregistrement CNAME dans la zone msdcs.machlinkit.biz :




***

Et voici quelques astuces....

Si nous voulons faire répliquer toutes les partitions (tous les contextes de nommage), sans devoir spécifier chacune, nous pouvons utiliser le paramètre "A". Je ne reproduis pas ici le rendu, assez prolifique.


Si nous voulons voir le "nom distingué" (Distinguished Name - DN) des partenaires de réplication, nous utilisons le paramètre "d" :

C:\>repadmin /syncall /d DC4 dc=machlinkit,dc=biz
Synchronisation de la partition : dc=machlinkit,dc=biz
MESSAGE DE RAPPEL : La réplication suivante est en cours :
    À partir de : CN=NTDS Settings,CN=DC3,CN=Servers,CN=Site-1,CN=Sites,CN=Configuration,DC=machlinkit,DC=biz
    Vers....... : CN=NTDS Settings,CN=DC4,CN=Servers,CN=Site-1,CN=Sites,CN=Configuration,DC=machlinkit,DC=biz
MESSAGE DE RAPPEL : La réplication suivante s'est terminée correctement :
    À partir de : CN=NTDS Settings,CN=DC3,CN=Servers,CN=Site-1,CN=Sites,CN=Configuration,DC=machlinkit,DC=biz
    Vers....... : CN=NTDS Settings,CN=DC4,CN=Servers,CN=Site-1,CN=Sites,CN=Configuration,DC=machlinkit,DC=biz
MESSAGE DE RAPPEL : Synchronisation totale terminée.
Synchronisation totale effectuée sans erreur.


Enfin, si je veux pousser un changement à Active Directory vers les autres partenaires du DC local, je peux recourir au paramètre "P" :

C:\>repadmin /syncall /P DC4 dc=machlinkit,dc=biz
Synchronisation de la partition : dc=machlinkit,dc=biz
MESSAGE DE RAPPEL : La réplication suivante est en cours :
    À partir de : 58d00eef-a083-47a5-9cf7-d854ac13bf79._msdcs.machlinkit.biz
    Vers....... : 75a4a675-5ee2-40c6-b693-718d57461eeb._msdcs.machlinkit.biz
MESSAGE DE RAPPEL : La réplication suivante s'est terminée correctement :
    À partir de : 58d00eef-a083-47a5-9cf7-d854ac13bf79._msdcs.machlinkit.biz
    Vers....... : 75a4a675-5ee2-40c6-b693-718d57461eeb._msdcs.machlinkit.biz
MESSAGE DE RAPPEL : Synchronisation totale terminée.
Synchronisation totale effectuée sans erreur.

Remarquez bien le changement de sens de la réplication en observant avec soin les GUIDs respectifs.

***

Pour une liste exhaustive de tous les paramètres pour REPADMIN, consulter cette page (qui semble n'exister qu'en version originale anglaise) :

Syntaxe REPADMIN


***


C'est la fin de la première partie de cette série d'articles au sujet de REPADMIN. Dans la seconde partie, je présenterai encore quelques commandes et ferai encore quelques remarques sur la réplication Active Directory.