Blog: Active Directory

I've run into this issue a few times over the past few months and the fix has been roughly the same each time. Typically, what will happen is that a user account is created in Azure AD with a specific username/UPN. Later on, an account will be synced from the on-premise Active Directory environment with the same username/UPN. Azure tries to automatically reconcile this during the sync by renaming the synced account and appending numbers to the end.

Naturally, this is a problem if you need the on-premise AD account to be the authoritative copy. The first thing to be resolved is whatever is causing the conflict in the first place. Once that is resolved, Azure won't automatically rename everything back. Not to mention that once the account is already synced, it won't auto update the account as the source has not been changed since the original sync.

Since deleting and re-creating the on-premise account isn't always the best option, your solution is fairly simple – update the attribute on the source side to some bogus value, force a delta sync, update the attribute back, and force a delta sync again.

For example, if the email address of your on-premise user is tuser@domain.com and the Azure AD account shows the SMTP attribute is listed as tuser5589@domain.com, update the primary SMTP value in the proxyAddresses attribute to tuser1@domain.com and force a delta sync. Azure AD should then show tuser1 as the primary SMTP value with tuser5589 no longer listed. Once you see that, change it back to tuser@domain.com and force another delta sync.

I've had to run through similar steps with the proxyAddresses and the UPN attributes for the conflicting objects.

One of our customers is hosting their servers with a hosting provider who also provides some other servers, like backups and patching. The hosting provider was unable to patch some of the servers for this customer. After investigating with the hosting provider, it was determined that they could patch all of the servers except for the domain controllers. The service account they were using was a Domain Admin so it should have been able to patch any server. I logged into another server as the service account and tried to access the admin$ share on one of the domain controllers, but was unable to do so.

After some investigation, I found that the Domain Admins group was not a member of the built-in Administrators group in Active Directory. The customer had removed the groups from the Administrators group and had manually put accounts in that group when necessary. This caused the service account the hosting provider was using to work on all of the member servers because Domain Admins had administrative rights to those servers, but they were unable to access the domain controllers because the service account was not an administrator on the domain controllers since it was not a member of the Administrators group. I am not sure why the customer removed the default groups from the Administrators group, so I just added the service account to the built-in Administrators group. The hosting provider attempted to patch the servers again and verified it was working properly.

I was helping out with a customer’s Active Directory migration and a different IT support group used a profile migration tool to help “ease” the transition between domains. But soon after the users started complaining that IE was not allowing them to save passwords. They would get prompted to store the credentials for a website and click yes, but as soon as they closed and reopened IE their stored credentials would disappear. Our suspicion was that the profile migration tool had corrupted the credential store in the registry.

I started a remote session with one of the users, checked the IE password store in the registry (HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2), and saw several of the user’s old entries. In order to allow the user to store passwords again, I had to delete this registry key, reopen IE, and save credentials for a website. Once I clicked “yes” to the prompt to save credentials, the registry key was automatically recreated and the credentials got stored.

After installing a new server and promoting it to a domain controller, the replication from the other domain controller did not work and the NETLOGON and SYSVOL folders were not created. Initially, I tried demoting it and re-promoting it, but that didn't work. I found the following Microsoft Support article - http://support.microsoft.com/en-us/kb/315457 - on how to rebuild the SYSVOL tree and it’s content in a domain. In summary, I had to go into ADSI and delete the orphaned GUIDs and create new symbolic links for both of the folders. I also had to recreate all of the group policies in order for them to work on the new server.

I needed a utility to export the members of a distribution group to a CSV or Excel file. After some searching I found several utilities from CTXadmtools including one that did exactly what I needed. [more]

http://ctxadmtools.musumeci.com.ar/ADGroupMembers/ADGroupMembers11.html

We recently ran across a problem where users trying to log on to Microsoft Office Outlook Web Access in Exchange Server 2007 would receive the following error message:
"A problem occurred while trying to use your mailbox. Please contact technical support for your organization."

If Show Details is clicked in this error message, a call stack including the following message appears:
"Exception message: Property Languages cannot be set on this object because it requires the object to have version 0.1 (8.0.535.0) or later. Current version of the object is 0.0 (6.5.6500.0)." [more]

After some research we found that this issue occurs when the msExchVersion attribute is not set correctly on the user object in the Active Directory. Exchange 2007 uses the msExchVersion attribute to determine the version of Exchange that user objects are associated with. If the version value is less than 0.1, Exchange 2007 considers the object "read-only" and cannot write changes to the object.

The msExchVersion attribute may not set correctly if you created the user's mailbox by using the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in instead of by using the Exchange 2007 Management Console, as was the case in this situation. 

To resolve this issue, type the following command at the Exchange Management Shell prompt:
Set-Mailbox User_Name -ApplyMandatoryProperties

To verify the msExchVersion attribute, type the following command at the Exchange Management Shell prompt:
Get-Mailbox User_Name | format-list ExchangeVersion

In Active Directory Users and Computers there is an Email Addresses tab that lists email addresses for the user.  One of these (for each protocol) is selected as the Primary.  The primary address will be the one that a user's outgoing email appears to come from.  But there is also a General tab where one can enter an email address for the user. This also causes that user's outgoing email to appear to come from that address.  Normally, changing one also changes the other.  But if you are running Active Directory Users and Computers from a machine that does not have the Exchange Server tools installed, the Email Addresses tab is not there and changing the email address on the General tab will not change the primary.  Actually, anything can be entered in that field on the General tab, even invalid domains.  So it is recommend to always make user account changes on the Exchange server, or at least on a system that has the Exchange server tools installed.  And use the Email Addresses tab to change user's email addresses.

Some email servers perform some verification on the sender's email address and may reject it if the domain is invalid.  Nothing can send a bounce message either because the email address does not work, so the sender will not know the email was not delivered.