Test Layout

When planning an Office 365 implementation, it is best practice to start by assuming that UPN for signing in to Office 365 should match the user email address. If you don't configure it this way, then users have two separate items (their UPN for signing in and their email address) that look very similar. In many cases users are confused by the similarity. If you are synchronizing  your on-premises Active Directory with Office 365 (in most cases you do) then you need to set the UPN for the on-premises user accounts with the correct UPN. The UPN from on-premises user accounts is synchronized to Office 365 to create the ID for signing in. Most organizations are not using the UPN on user accounts for authentication on-premises. The option has been there since Windows 2000, but most organizations still use the domainname\username format for authentication. However, you need to verify if any user accounts are using the UPN for authentication before making this change. At minimum, you sho...

When managing email addresses and domains in Exchange Server, old email addresses are never removed automatically. This is good because it ensures that email addresses on a mailbox are never accidentally lost. However, you may want to clean up old domains or address formats that are no longer in use. Some common scenarios where you might want to remove an old domain: An SMB deployment of Exchange Server where a .local domain was added as the first domain for email addresses. Old GroupWise addresses are left in place from an older migration. Obsolete domain left over from a company merger many years ago I often find that obsolete domains are identified when I run IDFix as part of preparing to migrate to Office 365. To simplify the removal of obsolete domains, I have created the following script. A few things to note: You need to set $RemovePattern to identify the domain to be removed. Any email addresses matching this pattern will be removed from proxyAddresses attribute in Active Direc...

I needed to update all UPNs in a domain today. It was pretty quick to figure out, but here is one line to take care of it for you. Get-ADUser -Filter * | ForEach-Object { Set-ADUser $_ -UserPrincipalName ($_.UserPrincipalName).Replace("OldDomain","NewDomain")} Remember to make the pattern in the OldDomain unique enough that you don't accidentally change things you don't intend to. For example, if you are changing from a .local domain in the UPN to a .com, make sure that you replace ".local" and not "local" on the off chance one of the user IDs includes "local" in the name. If there are any user accounts without a UPN, then an error is generated for those accounts. My domain had 4 accounts without a UPN: krbtgt - default account used for kerberos IWAM_ServerName - Old IIS account from Windows 2003 IUSR_ServerName - Old IIS account from Windows 2003 support_XXXXXXX - Used by Help and Support service

I was wanting to collect some performance information on a Windows 2008 R2 domain controller. One of the things you may not realize is that Windows Server includes some predefined data collector sets for common tasks and generates reports based on the data. Since I was having a performance issue on the DC, I wanted to run the Active Directory Diagnostics data collector set. Built-in data collector sets When I attempted to start the Active Directory Diagnostics data collector set (or any of the other predefined data collector sets), they didn't start. There was no error message or any indication of what the error might be. Ultimately my workaround was to create a new data collector set with the same settings. Fortunately, when you create a new data collector set, one of the options is to create from a list of templates, which includes Active Directory Diagnostics. The new data collector set ran without any issues. Selecting a template for a data collector set

I've been working with a larger client for the last several months on Active Directory (AD) issues. One of the ongoing small issues has been AD monitoring alerts generated in System Center Operations Manager (SCOM) when it appears nothing is actually wrong. The alerts were appearing intermittently on several of the servers, but not all. We were seeing alerts like this: Failed to ping or bind to the Infrastructure Master FSMO role holder AD Op Master Response : The script 'AD Op Master Response' could not determine the schema Op Master.The error returned was: 'LDAP://DC.contoso.com/RootDSE' (0x8007203A) Failed to ping or bind to the Schema Master FSMO role holder AD Op Master Response : The script 'AD Op Master Response' could not determine the schema Op Master.The error returned was: 'LDAP://DC.contoso.com/RootDSE' (0x8007203A) Failed to ping or bind to the RID Master FSMO role holder AD Op Master Response : The script 'AD Op Master Response'...

One of the basic tasks you can do to verify Active Directory replication health is to run RepAdmin.exe /ReplSummary. The question becomes, what exactly do the results mean? If you’re looking for a quick analysis, here it is. With no fails and all largest deltas less than 1 hour, you’re all good. Now, for a more detailed look… Total is the number of replication connections that a domain controller has with other domain controllers. The number of connections is probably higher than you expect because a separate connection is created for each Active Directory partition that’s being replicated. Most of the time you will have 5 per domain controller (domain, configuration, schema, DomainDnsZones, ForestDnsZones). Fails is the number of connections that are not replicating properly. The number of fails should be zero. Largest delta is where some of the confusion comes in. This is the longest period of time that a connection has not been used between two domain controllers. So, if a domain co...

I'm working on some Active Directory (AD) disaster recovery projects right now and one of the recovery methods we're implementing is AD snapshots. With AD snapshots, you have a copy of your AD data to identify and recover from accidental changes. The client I'm working with has Windows 2008 R2 with PowerShell 2.0 for their domain controllers. PowerShell is my preferred method for automating anything at this point but AD snapshots don't have any PowerShell cmdlets. Fortunately Ashley McGlone, a Microsoft PFE, has created some PowerShell functions that help you manage and use AD snapshots. One of the coolest things in there is a function (Repair-ADAttribute) that lets you pull attributes from the snapshot and apply them to the same object in the production AD. You can read more about these functions and download them from these two locations: https://blogs.technet.microsoft.com/ashleymcglone/2014/04/24/oh-snap-active-directory-attribute-recovery-with-powershell/ https://g...

I'm working on project where we needed to set AD security permissions in a test environment based on the permission based on production. When I generated a report of AD permissions that had been applied, several of the entries came back with SID numbers instead of user or group names. Typically this means that the user or group has been deleted, but I wanted to confirm. I wanted to take the SID and identify the user or group account that was associated with it. After a quick search I found a few examples that looked similar to this: $objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-21-1454471165-1004335555-1606985555-5555") $objUser = $objSID.Translate([System.Security.Principal.NTAccount]) $objUser.Value Above example taken from: https://technet.microsoft.com/en-us/library/ff730940.aspx It seemed to me that there had to be an easier way using the ActiveDirectory module for PowerShell which isn't used by these examples. Good news, there is...