Monday, September 26, 2016



Hello friends , On this Post i will discuss one of the error that you might come across while upgrading Exchange 2007 SP1  to it’s higher service pack or Roll up update. While upgrading you might get a pop up “Click ok to try again, or enter an alternate path to a folder containing the installation package ‘Exchangeserver.msi’ in the box below” . The pop up will ask you to redirect you the correct .msi file however even if you point the the file to the correct .msi file it wouldn’t take it. Eventually the only option is to cancel the upgrade. If you check the Exchangesetup.log you will get error like this.
[ERROR] Unable to remove product with code 24b2c164-de66-44fe-b468-a46d9d5e6b31. The installation source for this product is not available. Verify that the source exists and that you can access it. Error code is 1612.
Below is the snapshot of the pop up windows that we get during the upgrade.



If you check the Exchangesetup.msilog , You will get below error.

MSI (s) (C0:E0) [03:04:45:354]: Machine policy value ‘DisableUserInstalls’ is 0
MSI (s) (C0:E0) [03:04:45:354]: Note: 1: 2766 2: C:\Windows\Installer\13253.msi
MSI (s) (C0:E0) [03:04:45:354]: Warning: Local cached package ‘C:\Windows\Installer\13253.msi’ could not be opened as a storage file.
MSI (s) (C0:E0) [03:04:45:354]: User policy value ‘SearchOrder’ is ‘nmu’
MSI (s) (C0:E0) [03:04:45:354]: User policy value ‘DisableMedia’ is 0
MSI (s) (C0:E0) [03:04:45:354]: Machine policy value ‘AllowLockdownMedia’ is 0
MSI (s) (C0:E0) [03:04:45:354]: SOURCEMGMT: Media enabled only if package is safe.
MSI (s) (C0:E0) [03:04:45:354]: SOURCEMGMT: Looking for sourcelist for product {24B2C164-DE66-44FE-B468-A46D9D5E6B31}
MSI (s) (C0:E0) [03:04:45:354]: SOURCEMGMT: Adding {24B2C164-DE66-44FE-B468-A46D9D5E6B31}; to potential sourcelist list (pcode;disk;relpath).
MSI (s) (C0:E0) [03:04:45:354]: SOURCEMGMT: Now checking product {24B2C164-DE66-44FE-B468-A46D9D5E6B31}
MSI (s) (C0:E0) [03:04:45:354]: SOURCEMGMT: Media is enabled for product.
MSI (s) (C0:E0) [03:04:45:354]: SOURCEMGMT: Attempting to use LastUsedSource from source list.
MSI (s) (C0:E0) [03:04:45:354]: SOURCEMGMT: Processing net source list.

To resolve the issue Download Windows cleanup utility. Microsoft has removed the Windows cleanup utility from their website however you will be able to find the application on many website for free download. Install the Windows cleanup utility and run the Application.
Note:- Removing entries using Windows clean up utility can cause severe issues to the server so make sure you take a back up before making any changes to the server.
Remove the below entries from the Windows cleanup utility.
1.Microsoft Exchange Server
2.Microsoft Exchange 2007 Enterprise Anti-Spam Signature
3.Microsoft Exchange 2007 Enterprise Block List Update
4.Microsoft Exchange 2007 Standard Anti Spam-filter Update

Please make sure you don’t delete any other entry other then the above entry.
Reboot the server. You should be successfully able to upgrade the Exchange 2007.

Friday, September 23, 2016



Hello Friends, In this post i will talk about how active directory replication works.
So before answering how active directory replication works i would like to brief about what is active directory replication and what are it’s dependencies.
Active Directory replication  is the copying of data from one DC to the other DC. When any administrator makes changes on any DC that change has to be replicated to all the DC’s within the same environment so that data throughout the domain remains consistent. The benefits of AD replication are as below.
~ Prevents a single of point of failure.
~ Provides load sharing and support growth​.
~ Clients can use one of many available servers for network service.

Dependencies of AD replication.
1) DNS:- The Domain Name System (DNS) that resolves DNS names to IP
addresses. Active Directory requires that DNS is properly designed
and deployed so that domain controllers can correctly resolve DNS
names of replication partners.
2)Remote Procedure call(RPC):- Active Directory replication requires IP
connectivity and the Remote Procedure Call (RPC) to transfer updates
between replication partners.
3)Kerberos v5 authentication:- The authentication protocol for both
authentication and encryption that is required for all Active Directory
RPC replication.
Multi master replication:- Active directory support multi master replication which means that the change can be made to any DC and once the change is made it will be replicated to all the Dc’s.
When any change is made to any object , The change value must be replicated. The most interesting part to note here is that only the changed attribute is replicated not the whole object. Every has object has multiple attributes, The best example will be an user in AD can have multiple attributes like username, password, Email etc. You can see the object attributes by the running the below command.
Repadmin /showobjmeta servername “Distinguished name of the object”.
I am attaching the snapshot of the same.
















In the above snapshot we have many information however if you see the column Attributes , You will be able to see all the attributes for the user msft. If msft user changes the password  then the password attribute will be replicated but  not the whole msft object. At the time of replication, only the current value of an attribute that has changed is replicated. If an attribute value has changed multiple times between replication cycles (for example, between scheduled occurrences of intersite replication), only the current value is replicated.
Active Directory data is separated in different partitions so when AD replication happens the data from one of these partition is replicated. There are 4 types of AD partitions.
1)Domain data that is stored in domain directory partitions
2)Configuration data:- Every domain controller stores one writable configuration
directory partition that stores forest-wide data controlling site and replication
operations.
3)Schema data:- Every domain controller stores one writable schema partition that
stores schema definitions for the forest. Although the schema directory partition
is writable, schema updates are allowed on only the domain controller that holds
the role of schema operations master.
4)Application data:- Domain controllers that are running Windows Server 2003 can
store directory partitions that store application data. Application directory
partition replicas can be replicated to any set of domain controllers in a forest,
irrespective of domain.
We can make only four types of changes in Active Directory hence only these four types of changes can be replicated.
1)Add an object to the directory:- An Add request makes a new object with a unique objectGUID attribute. The values of all replicated attributes that are set by the
Add request are stamped Version = 1. This GUID can be seen from adsiedit.msc

2)Modify (add, delete, or replace) attribute values of an object in the directory:-
Add:- The attribute value is added.
Delete:- The attribute value is replaced by NULL.
Replace;- Replace the attribute  value with the current value.
3)Move an object by changing the name or parent of the object.
4)Delete an object from the directory.:- Sets the isDeleted attribute to TRUE, which marks the object as a tombstone (an object that has been deleted but not fully removed from the directory).
Active Directory uses Update sequence Number (USN) for tracking and managing  updates which has to be replicated. Update sequence number is an increasing local counter of a DC. Update sequence Number can never run backwards. A source domain controller uses USNs to determine what changes have already been received by a destination domain controller that is requesting changes. The destination domain controller uses USNs to determine what changes it needs to request.
USN is a 64-bit counter that is maintained by each Active Directory domain controller as the highestCommittedUsn attribute on the rootDSE object. At the start of each update transaction (originating or replicated), the domain controller increments its current USN and associates this new value with the update request. You can see this value in adsiedit.msc as well as using repadmin command line.

















Before we dig more in to USN to understand AD replication , It is very important to understand few terminology.
1)Local USN:- Every attribute of an object has it’s own USN so local USN is the USN of each attribute of an object. If you see the first picture of this post , you will be able to see the local USN of all the attributes of msft user. You can see the local usn of all the attributes of an object by running the below command.
Repadmin /showobjmeta servername “Distinguished name of the object”
2)USNChanged:-The maximum local USN among all of an object’s
attributes is stored as the object’s USNChanged attribute. You can see this USNchanged
attribute from adsiedit.msc on the object properties.
















3)Originating USN: For an originating write only, the update’s USN value
is stored with each updated attribute as the originating USN of that
attribute. In very simple words Originating USN is the updated USN value for every attribute of an object, Again this is seen on the first image of the post. You can see the originating USN by the running the same command.
Repadmin /showobjmeta servername “Distinguished name of the object”
Let us assume a situation where we have two Domain controller DC and DC1.
We will  see how the replication will happen when we create a user mstest on Domain controller DC.When the user mstest was not created the USN of the Domain controller DC was 57513.

Now once we add the mstest user on domain controller DC , The USN of DC changes to 57521.

The USN of DC1 before the replication of the user was 37021 which after replication is increased to 37031. Now we will see the attributes of mstest user both on DC and DC1.
Below image shows the  attributes of mstest user on DC, Just after creating the user on DC.
















so on the above image you can see the local USN and the originating USN of every attribute of mstest user. Since the user was created on DC the local USN and originating USN is same for all the attributes. Now let us  see the user attributes of mstest user on DC1 after the replication.
















Now on the above image if you see the local USN  and originating USN is different since the originating USN is carried forwarded from DC(Source domain controller).
Now AD Replication uses two values for Replication Request Filtering.
1)Up-to-dateness vector:- The up-to-dateness vector is a value that the destination domain controller maintains for tracking the originating updates that are received from all source domain controllers. The source domain controller uses this value to reduce the set of attributes that it sends to the destination domain controller. When a destination domain controller requests changes for a directory partition, it provides its up-to-dateness vector to the source domain controller. On the basis of this value, the source domain controller can determine that the destination does or does not have an up-to-date value (or multivalue) for an attribute, and it sends updates accordingly.  The up-to-dateness vector helps the source domain controller to filter irrelevant attributes since the destination Domain controller presents  it’s  originating updates to the source DC and then after comparing the originating updates of both the DC’s updates are replicated to the destination DC.You can see the up-to-dateness vector in the output of the
repadmin /showvector command
2)High-watermark (direct up-to-dateness vector):- The high-watermark is a value that the destination domain controller maintains to keep track of the most recent change that it has received from a specific source domain controller for an object in a specific directory partition. The source domain controller uses this value to filter the objects that it considers for replication to the destination.When a destination domain controller requests changes to a directory partition from a source domain controller, the source domain controller provides the changes in increasing order of the usnChanged attribute value.the destination domain controller keeps track of the usnChanged value of the most recent object it successfully received from the source domain controller for a specific directory partition. The replication happens after comparing the usnChanged attribute of the source and destination domain controller. you can see the High-watermark value of every partition by running the below command.
repadmin /showreps /verbose , Look at the USN value for all the partitions in the below image.
















Multi master Conflict Resolution Policy:- AD uses the method of volatility(Number of changes) as the first method of conflict resolution and the second method it uses is timestamp. Every attribute of an object  has a version number attached to it. when the object is created for the first time the version of all the attribute is given the value 1. When any attribute of any object is changed then the version number of that attribute is increased by 1 so if the password is changed for a user for the first time then the version number for password attribute will change from 1 to 2. The version number with greater value comes in to effect  during conflict. let us assume some scenarios to understand the Multimaster Conflict Resolution Policy.
Senario 1 :- We have two Domain controller DC and DC1, The password attribute of the user mstest is changed on DC and the email attribute of the user mstest is changed on DC1. The version number  of password attribute is changed from 1 to 2 in DC and the version number of email attribute is changed from 1 to 2 in DC1 , Remember the password attribute’s version number(which is 1) didn’t change in DC1 and so is the  Email attribute’s version number(Which is 1) in DC. When the replication will happen the version number(value=2) of password  attribute of DC > version number(value=1) of password attribute of DC1 hence password of DC will come in to effect . The version number(value=2) of Email attribute of DC1> Version number(value=1) of email attribute of DC so email address of DC1 will come in to effect.
Scenario 2:- We have two Domain controller DC and DC1, The password attribute of the user mstest is changed on DC and the same attribute of mstest object is changed on DC1. In this scenario the version number for password attribute is increased to 2 on both the Domain controller’s DC and DC1, now it is a tie so AD uses the time stamp as the second method for conflict resolution. The password of the Domain controller with the latest time time stamp will come in to effect. You can see the version of all the attributes of an object by running the below command.
Repadmin /showobjmeta servername “Distinguished name of the object”

I have tried to cover all the important points that should be covered under Active Directory replication however if you feel that i haven’t touched any point then feel free to leave a comment so that i can discuss the same topic on my next post.


Hello Friends, On this Post i will show you how to create Disclaimer using Transport rules on Exchange 2010. The Disclaimer will be added automatically on every email sent inside or outside the domain. You can customize the transport rules for achieving different results according to your need.
Open EMC -> Organization configuration->Hub transport role -> Transport roles , Right click and create a new transport role.


Here i have created a new Transport Rule and named it as Disclaimer_Test, You can name the transport agent anything according to your convenience.














Don’t check any option on the conditions check box, If you Don’t check any option that implies that the transport rule will apply to the messages. Below is the snapshot of the same.
















Hit yes on the pop up and click next, Check the option “Append disclaimer text and fallback to action if unable to apply”



























On the Bottom, Click on the Disclaimer text link and Add the Disclaimer text that you want to be sent to all the messages. 
















Hit next , On the Exceptions window leave all the boxes unchecked since we don’t want to create any exceptions and then hit new and create the new transport rule.















Now the transport rule is created. Restart the Microsoft Exchange transport service.
Open OWA or Outlook and try to send an email. You will see that the disclaimer text is added to all the emails sent out from the domain.












That is all we need to do add a disclaimer on all the messages sent out from the domain.


Thursday, September 22, 2016



Hello Friends, On this post i will talk about how you can repair a mailbox database in Exchange 2010/2007. Exchange database can get corrupt because of a power outage or due to some corrupt emails. If the mailbox database is in dirty shutdown then you will not be able to mount the Exchange database, You will have to follow the below steps to mount the database successfully.
Note:- Always take a back up of the mailbox database.edb file and the log files before making any changes to the Exchange database.

First of all we will have to check the status of the mailbox database. Open Exchange management shell and run the below command to check the status of the mailbox database.
eseutil /mh “Location of the database”
Below is the snapshot of the same , However in this scenario the database is in clean shutdown. In case the database is not in clean shutdown then its state will be Dirty Shutdown.



To repair the database run the eseutil /p switch, Remember the /p switch is hard repair hence you might lose some data. It is always recommended to take a back of the database(.edb file ) and the log file before the repair. below is the command to initiate a hard repair on the mailbox database.

eseutil /p “Location of the database”
Sample command:-
Eseutil /p “C:\program files\Microsoft\Exchange server\V14\Mailbox\mailbox database.edb”


Once you initiate the hard repair , You will receive a warning stating that some of the data might be lost , Click ok to to the pop up. Now the repair will start and the repair will take time so be patience about it. Normally the eseutil repairs a mailbox database at a speed of 7 – 8 Gb /hr however the time of the repair is directory proportional to the size of the mailbox database and the level of corruption on the mailbox database. Once the repair completes then again check the status of the mailbox database by running the eseutil \mh command . If the database is in dirty shutdown then move the database log files to a different location. You will be able to get the location of the log files by running the below command.
Get-mailboxdatabase -identity “mailbox database,edb”  | fl *path*
The highlighted part is the location of log file.

Go to the log file location and move(Cut and paste) all the log file from that location to a different location,By default in Exchange  the log files and the mailbox database.edb file resides on the same location so only keep the mailbox database.edb file only and move all the log files to a different location. Now we need to open Exchange management Console, Go to Organization configuration->Mailbox->Database management->Properties of the mailbox database->Maintenance ->Check the option “This database can be restored from a back up”.Go ahead and mount the database and you will be able to mount the mailbox database.