Fun with the Offline Address Book (OAB)
As companies adopt Outlook 2003 cached mode for their users, the Offline Address Book ( OAB ) becomes increasingly important. When Outlook 2003 users open the GAL or use name resolution, the OAB is used instead of making requests to a Global Catalog server. The OAB itself consists of a set of .OAB files which are attached to a message object and stored in a special public folder (commonly called a system folder). The size of these files will vary depending on how many mail-enabled users you have in the Active Directory and how many attributes are present on each object. In my travels, I find that a good back-of-the-envelope guide is 1MB per 1000 users. The OAB is typically generated once a day. OABGen, which is part of the Exchange System Attendant process (Management and Administration Daemon or MAD) runs on one nominated Exchange server. First of all it looks at the previous day's OAB, and creates a new message object with an attached changes.oab file. This includes all the changes that were made in the past 24 hours, and is the mechanism that Outlook uses to download incremental updates. Next, OABGen will refresh the main .OAB files which is a complete copy of the offline address book. The OAB system folder (called OAB Version 3a in Exchange 2003) has a default aging limit of 30 days. This means that the Exchange server retains 30 days worth of changed objects until it starts automatically removing old generations. This means that Outlook users can download incremental OAB updates at up to 30 day intervals. If you download the OAB today, then wait 35 days and attempt to download an incremental update, you won't be able to; and Outlook will automatically download the full OAB again. If you want to look at the size of your OAB files, you can use a little-known trick in ESM from Exchange 2003. Drill down to the Public Folders node, then right-click, and choose View System Folders. Once here, you can find the OAB Version 3a folder, and in the tabs on the right-hand side, choose Content. You should be able to see the last 30 days worth of changes.oab and one larger object containing the complete set of OAB files. The "inline OWA" within ESM will also tell you the file sizes of each attachment. Finally, a word of warning. There are some instances where Outlook will need to download the complete OAB, even though you expect only the changes to be downloaded. The first scenario is where more than 1/8th of the GAL has been modified in the past 24 hours. The second scenario is when you've added a new Administrative Group to your topology. The latter can be an unexpected 'gotcha' if you don't know about it. Paul BowdenCross Org mailbox migration cleanup with Exchange Server 2007
After performing a Cross Org mailbox migration, administrators need to enable mail redirection from the source to the target forest. Even though GALSync remains the recommended tool for this purpose, the initial synchronization process can take some time which means that messages queued during the move and messages sent from users in the source forest before the contacts objects were created will NDR. To address this issue, Exchange 2007 added to Move-mailbox a parameter called SourceMailboxCleanupOptions to determine what "source cleanup" will be done after the move. For RTM, this parameter accepts 2 options: DeleteSourceMailbox: Deletes mailbox attributes from source user DeleteSourceNTAccount: Deletes source user AD object These two options don't address completely the issue but allow easier scripting than we had in the Exchange 2003 days. To fully support our additional cleanup needs we have added 2 new options for this parameter in SP1: CreateSourceContact: Deletes source user AD object and creates a contact on the source forest that points to the mailbox just moved to the target forest MailEnableSourceAccount: Deletes mailbox attributes from source user and mail enables the source user so it points to the mailbox just moved to the target forest Workaround for Exchange 2007 RTM: A cross org migration cleanup script As I mentioned above, our RTM version has an improved but incomplete "cleanup" functionality. To help our customers to perform these cleanup options before Service Pack 1 is released, I have created a PowerShell script that provides similar functionality: It creates a mail enabled contact (when the option to delete the source user is used) or it can mail enable the user account (when the option to delete the source mailbox attributes is used). It is worth noticing that this script has some limitations when compared to our SP1 move-mailbox task: It has to be executed from the source Forest Logging is not as detailed as the actual move-mailbox native log Since the script needs to be executed from the source Forest it will not work when the source Forest does not have a Exchange 2007 server installed Here is an overview of the steps performed by the script: Pre-validates CSV and parameters Store data about mailboxes that will be moved to be used later Try to move all mailboxes. Check whether task was successful. If not, stop execution Use the newly moved mailbox primary SMTP address as the External email address If creating a contact: Creates contact object and uses mailbox display name as contact name Use mailbox alias as alias if creating contact Copy proxies from moved mailbox as secondary proxies Try to add target mailbox SMTP to proxy collection (it is necessary if address was calculated for a Ti target server) Add target mailbox LegDN as X500 to proxy collection Here is an example of a mailbox migration using the script: Step 1 – Create variables that hold credentials for source and target Forests $source = get-credential $target = get-credential Step 2 – Create a csv file that contains information about the mailboxes you want to migrate (for example, mailboxes that have contain Paul in identity) get-mailbox Paul* | export-csv C:\users.csv Step 3 – Call script passing all necessary information: C:\migrationCleanup>.\migrationCleanup.ps1 -SourceGlobalCatalog sourceServer.SourceDomain.com -SourceDomainController sourceServer.SourceDomain.com -DomainController targetServer.TargetDomain.com -GlobalCatalog targetServer.TargetDomain.com -NTAccountOU 'CN=Users,DC= TargetDomain ,DC=com' -ContactsOU "Users" -UsersFile "C:\users.csv" -TargetDatabase " targetServer \Mailbox Database" -SourceMailboxCleanupOptions DeleteSourceMailbox -SourceForestCredential $source -TargetForestCredential $target -TargetSMTPDomain "TargetDomain.com" In this example, I had the following server configuration: -SourceGlobalCatalog sourceServer.SourceDomain.com -SourceDomainController sourceServer.SourceDomain.com -DomainController targetServer.TargetDomain.com -GlobalCatalog targetServer.TargetDomain.com -NTAccountOU 'CN=Users,DC=FRICIB-dom,DC=extest,DC=microsoft,DC=com' -ContactsOU "Users" -UsersFile "C:\users.csv" -TargetDatabase " targetServer\Mailbox Database" -SourceMailboxCleanupOptions DeleteSourceMailbox -SourceForestCredential $source -TargetForestCredential $target -TargetSMTPDomain "TargetDomain.com" Most parameters work the same way they do in move-mailbox. The exceptions are –ContactsOU, which determines where your source contact will be created and the parameter –TargetSMTPDomain, which is used when moving mailboxes to legacy Exchange servers. In these cases, the target SMTP address is stamped in the target mailbox by the RUS, which means it might not be present right away. Since we need that target address to be used as the –ExternalEmailAddress of the newly created source mail contact or mail enabled user, we will use the –TargetSMTPDomain parameter along with the alias of the source mailbox as a substitute for it. Besides the limitations mentioned earlier (and all the optimizations I know you will come up with), this script should work just fine and allow you to avoid the large majority of NDRs for email sent during and after a Cross Org mailbox move. You can get the migration cleanup script as an attachment to this blog post. - Paul MacKnightGuidance on Active Directory design for Exchange Server 2007
This post focuses on two aspects of Active Directory (AD) design for Exchange 2007: The recommended ratio of Exchange 2007 servers to Active Directory global catalog (GC) servers When to use dedicated Active Directory sites for your Exchange 2007 servers While most of the existing guidance about AD design for Exchange 2003 applies to Exchange 2007, there are several new factors that must be considered: Exchange 2007's new 64-bit architecture Availability and mix of both 32-bit and 64-bit AD servers New (or upgraded) services and clients (Unified Messaging, anti-virus/anti-spam, Outlook 2007, etc.) New role separation and architecture for Exchange 2007 servers (Mailbox, Hub, Client Access Server, Edge, UM.) More use of advanced features by typical users (mobile devices, calendaring, etc.) Increasing average mail traffic and storage allowances Additional message handling (anti-spam/antivirus, compliance features) requires more GC network bandwidth and processor utilization per user/message How Many Global Catalog Servers Do I Need for My Exchange 2007 Servers? The previous recommendations for Exchange 2003 are available at: Global catalog server placement and ratios in an Exchange 2000 Server organization or in an Exchange Server 2003 organization The primary recommendation in the above article is that you should have 1 Global Catalog processor core per 4 Exchange server processor cores. It is important to note that this is not a 1:4 ratio of servers or even processors, but of processor cores: a dual core processor counts as 2 when doing the ratio calculations. With Exchange Server 2007, Microsoft recommends that you deploy one 32-bit GC CPU core for each four Exchange 2007 mailbox server CPU cores. While the other server roles will influence the number of GC cores required, the Mailbox servers that are deployed influences the deployment of each of the other roles, so basing the number of GC cores on mailbox server cores will suffice. For example, suppose you have an 8 processor (single core) Exchange 2003 mailbox server. This Exchange server's Active Directory needs can be satisfied by two single-processor/single core GC machines, by one dual-processor/single core machine, or by a dual-core single-processor GC. The Exchange 2003 recommendations have been based on domain controllers running 32-bit Windows 2003. Something wonderful happens when you upgrade your domain controllers to 64-bit Windows 2003: efficiency can double! Instead of a 1:4 ratio, you can have a 1:8 ratio between Global Catalog processor cores and Exchange server cores. This assumes that you fulfill one critical requirement: You must have enough RAM installed on the 64-bit server to cache the entire Active Directory database in memory. To check the size of your Active Directory database, look on a global catalog server for the NTDS.DIT file. This file is installed by default in %WINDIR%\NTDS. On a 32-bit machine, no matter how much RAM you install, you're unlikely to be able to cache the whole database unless it is less than 1.5-1.7 GB in size. This is because of inherent memory addressing limitations in the 32-bit platform. For more details about why this is so, see the article links below. On 64-bit Windows, with its massively larger address space compared to 32-bit, you can cache even very large Active Directory databases entirely in RAM. This gets you a significant speed boost in responding to queries along with a dramatic reduction in expensive disk I/O. (If you're thinking, well, my AD database is a couple of gigabytes in size, but what if I were to use the /3GB switch to get some extra 32-bit address space for cache? Theoretically, yes, you can increase the amount of cache this way. As a practical matter, you would likely only get about 2.5-2.7 GB consistently in cache, and that would come at the price of system stability. Use of the /3GB switch on domain controllers is discouraged because it is likely to starve the machine of critical kernel resources. When this happens, the typical result is that after several days or weeks of operation, or after a peak in client demand, the server becomes unstable or unresponsive.) When you upgrade to 64-bit domain controllers, be sure you install enough RAM to cache your entire Active Directory database with some room to spare. Remember: if you don't install enough RAM, your performance will be more like a 32-bit domain controller. Keep in mind that these ratio recommendations are rules- of-thumb, not guaranteed numbers. Your environment may have unusual loads or configurations. Also, if you keep using 32-bit domain controllers with 64-bit Exchange Mailbox servers, you may skew the standard 1:4 recommendation. The ratio recommendation assumes that the DCs and the Exchange Mailbox servers are both on roughly equivalent hardware. But a 64-bit machine is likely to have more advanced processors and other components (busses, memory, etc.). If using older domain controller machines, you may need to lower the ratio. Standard benchmarks, such as the SPEC benchmarks (www.spec.org) , can give you a more realistic basis for comparing older to newer machines. The Performance Tools included in the Toolbox section of Exchange 2007's Exchange Management Console application can be very useful in reporting actual performance and finding bottlenecks. For more detailed recommendations, including lists of performance counters to monitor, take a look at these blog posts and white papers: Measuring AD Performance (Exchange Team Blog post) Active Directory Performance for 64-bit Versions of Windows Server 2003 (Windows white paper) Exchange 2007 Processor and Memory Recommendations (Exchange Team Blog post) Microsoft Windows Kernel Memory Management and Microsoft Exchange Server (Exchange Team Blog post) Best Practice Active Directory Design for Exchange 2000 (Exchange white paperâ??still highly applicable to Exchange 2007) Planning a Microsoft Exchange Server 2003 Messaging System (Exchange white paperâ??also a good resource that mostly applies to Exchange 2007) Regardless of your GC processor platform, you should expect some increase in network traffic between GCs and Exchange 2007 servers. This increase may be sizeable if you are taking full advantage of all the new features and roles in Exchange 2007 (antivirus, anti-spam, legal compliance features, unified messaging and so on). At Microsoft, when all of these features are heavily used, the network traffic between AD and Exchange nearly doubles. While this is a substantial increase, it has not had a large practical effect. Historically, network bandwidth has not been a common bottleneck between Exchange and Active Directory. Nonetheless, you should check your current utilization and be sure you have enough network bandwidth between Exchange servers and domain controllers as you deploy additional Exchange 2007 features. Should I Use Dedicated Active Directory Sites for My Exchange 2007 Servers? The short answer to that question is, No, not if you're creating a dedicated site only for the purpose of domain controller load balancing. This is a different answer than for Exchange 2003, so it needs some explaining. In Exchange 2003, message routing and Active Directory site topology were independent of each other. The primary reason to dedicate an Active Directory site to Exchange was to prevent other services and applications from hogging domain controllers needed by Exchange. (Or, to take a less Exchange-centric view of the universe, to prevent Exchange from hogging the DCs needed by other services.) In Exchange 2007, message routing maps directly to Active Directory site topology. Your AD site topology should therefore make sense for message routing, not just for domain controller load balancing. You should avoid creating an Exchange-dedicated Active Directory site unless doing so makes routing better too. Fortunately, the extra headroom available with 64-bit GC servers makes it easier for demanding applications to coexist in the same site, further reducing the motivation to use dedicated sites for Exchange 2007. Let's define a "demanding application" as one that: Continuously generates a large number of LDAP queries Requires ANR (Ambiguous Name Resolution) to resolve a good percentage of those queries, and Makes frequent authentication requests against domain controllers If you have multiple demanding applications running in a site, you must think not only about their average loads, but also about their peak loads, and the possibility that all of those applications may all at once decide to pick on a single domain controller. As a rule-of-thumb, if you are using 32-bit domain controllers, then Exchange is likely to coexist happily with other demanding applications in a site with up to 10,000 Exchange users. If you are using 64-bit directory servers, you can support up to 20,000 Exchange users in the same site with other demanding applications. Exchange does a pretty good job of load balancing its requests across the domain controllers available to it, including taking into account how busy the DCs are with other work. So Exchange is not likely to be the site bully. But it is a demanding application and will present steady, relatively high load across all the GCs available in the site. If you are above the peak limits described above, you should look at ways to dedicate directory resources to Exchange. That does not necessarily mean isolating Exchange to another site: You can try to reserve domain controllers for Exchange use by being clever with DNS. By appropriately configuring SRV record priorities and weights, you can often get nearly the same effect as a dedicated site. More about how to do this can be found here: Creating an Active Directory Site for Exchange Server (Ignore the first part of this paper and scroll down to the part about how to "Isolate Client Authentication Traffic from Exchange Facing Domain Controllers.") You can define a static set of domain controllers for use by a particular Exchange server (using the set-ExchangeServer cmdlet). This lets you keep Exchange from using domain controllers dedicated to other applications. While this is preferable to creating a dedicated site, it is not optimal from the perspective of ongoing management. You have to remember which GCs belong to whom and manually tune and maintain lists instead of letting Exchange automatically optimize the load balancing. If another application cannot be prevented from overwhelming the domain controllers Exchange needs, then investigate your options for restricting or isolating that application before deciding to protect Exchange in a dedicated site. If you have more than five Active Directory sites in your environment try very hard not to put Exchange 2007 in a dedicated site. In an environment more complex than five sites, it's unlikely that you will be able to design a dedicated site topology that works well for routing. Yes, you can then wrestle the Exchange 2007 routing topology into the shape you want without regard to the AD site topology. But you don't want the ongoing headache of managing and maintaining a message routing topology and an AD site topology that don't mesh together. Exchange and Active Directory are deeply entwined. Exchange 2007 takes advantage of this synergy to simplify message routing and make it more deterministic (and easier to troubleshoot). Let that work in your favor. If your Exchange routing needs are completely at odds with your AD site topology, it may be time to rethink both together. To summarize all this: 64-bit Active Directory servers are great news for Exchange and can double the performance of 32-bit servers. Take advantage of the doubling in performance you can get with 64-bit Active Directory servers. You can reduce the number of AD servers required to support Exchange and simplify both your Active Directory site and Exchange message routing topologies. - Mike LeeManaging OAB in Exchange Server 2013
The Exchange team blog article OAB in Exchange Server 2013 introduced the new Offline Address Book (OAB) generation and distribution architecture in Exchange Server 2013. Take a few moments to visit the article if you haven’t seen it yet or re-visit it for a quick refresher. The OAB management and administration is different in Exchange 2013 because of architecture changes. Additionally, the new Exchange Admin Center does not currently have options for managing OABs. This means that, at this time, you will need to use Exchange Management Shell for OAB-related tasks. This article takes you through commonly performed tasks in OAB administration and has a couple of real life scenarios to help understand the tasks better. Note: If you are in multi-forest Active Directory domain environment, make sure the Shell session has ViewEntireForest is enabled, else some of the commands in the article won’t return any output. Command to enable ViewEntireForest: Set-ADServerSettings -ViewEntireForest $true Creating a new OAB Creating a new OAB in Exchange 2013 no longer uses the -Server parameter. In order to create a new OAB, you should only specify the address lists to be required. The following example creates OAB for address list named “Global Address List FAB” New-OfflineAddressBook -Name OAB-FAB -AddressLists "Global Address List FAB" Identify the OAB generation server(s) The arbitration mailboxes in Exchange Server 2013 are assigned certain “Persisted capability” that defines the purpose/function of the arbitration mailbox. An arbitration mailbox with Persisted Capability “OrganizationCapabilityOABGen” is responsible for OAB generation. We will refer this mailbox as “Organization Mailbox” throughout the article. Exchange Server 2013 mailbox server hosting the Organization Mailbox will generate all OAB’s defined in the environment. For a non-DAG environment, use following command to identify the OAB Generation servers: Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,servername For a DAG environment, identifying OAB generation server(s) is a two-step process. Step1: Identify the mailbox database hosting organization mailbox with OAB Gen capability. Use the following command to list the arbitration mailboxes with persisted capability of OABGen and database on which this mailbox is hosted: Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,database Step2: Identify the mailbox server where the database hosting organization mailbox is mounted Use following command to identify active copy of mailbox database: Get-MailboxDatabaseCopyStatus db1 The server where database status is “mounted” is the current OAB generation server. Change the OAB generation server There are two methods of changing the OAB generation server. Move mailbox Move the organization mailbox to a mailbox database on a server intended to be designated as OAB Generation server. Example: DB1 is a single copy database present on the server Exch1 and hosts the organization mailbox. DB2 is mailbox database present on Exch2. The following command can be used to move the organization mailbox to DB2 and make Exch2 the OAB generation server. Get-Mailbox -Arbitration -database db1| where {$_.PersistedCapabilities –like “*oab*”} | New-MoveRequest -TargetDatabase db2 This method is more suited for environments that have single copy of mailbox database hosting the Organization Mailbox. Activate the mailbox database on another server This method is suited for environments that have multiple copies of the mailbox database hosting Organization Mailbox. Example: DB1 hosts the Organization Mailbox and has copies on servers Exch1 and Exch2. DB1 is currently active on Exch1. The following command can be used to activate DB1 on Exch2 and therefore make it the OAB generation server: Move-ActiveMailboxDatabase DB1 -ActivateOnServer Exch2 Note: Review guidelines mentioned in “Placement of Organization Mailbox” below before changing the OAB Generation server. Creating a new Organization Mailbox Administrators can create additional Organization Mailboxes for fault tolerance or for serving users in a geographically disbursed Exchange deployment. Creating a new Organization Mailbox is a two step process: Step1: Create a new arbitration mailbox New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB Mailbox for Seattle” Step2: Enable OABGen capability Set-Mailbox -Arbitration oabs -OABGen $true -MaxSendSize 1GB Note: Review guidelines mentioned in “Placement of Organization Mailbox” below before creating additional organization mailboxes. Changing the OAB Generation Schedule The OAB Generation till Exchange Server 2010 was based on a “Schedule” set on OAB properties. You might see a “Schedule” defined when viewing properties of Exchange 2013 OAB. But, the Exchange Server 2013 OAB generation does not take place according to the “Schedule” defined on OAB properties: Instead, Exchange Server 2013 OAB Generation takes place according to OABGeneratorWorkCycle and OABGeneratorWorkCycleCheckpoint properties configured at the Mailbox Server. Example: The values in the above screenshot mean OAB is generated once every day. Which Mailbox Server processed the OAB download request? The Exchange Server 2013 CAS role proxies the OAB download request to an appropriate Mailbox role server. The CAS role maintains log of each request it handles in the log files, present in folder %ExchangeInstallPath%\Logging\HttpProxy\OAB\ These log files are an excellent tool to identify which mailbox server the CAS chose to serve the request. Information of some important fields from the log file: Field Description UrlStem Useful to identify the OAB being downloaded and also if this was a full download or incremental download AuthenticatedUser Name of the User requesting the OAB AnchorMailbox DN of Organization Mailbox identified as the closest to serve the OAB request ServerHostName CAS Server Name handling the request HttpStatus Status code for Proxy action ProxyAction Action CAS Server performed for the request, it will be mostly “Proxy” for Exchange 2013 OAB TargetServer Name of Mailbox role server to which request was proxied The log file can be imported in Excel for better readability. Example: Forcing the OAB Generation The Exchange Server 2013 OAB generation can be forced to start immediately by two methods. Method 1: Update-OfflineAddresBook Below command will force OAB generation of an OAB named "Default Offline Address Book" across all organization mailboxes. Update-OfflineAddressBook "default offline address book" Note: This command initiates an RPC request to each mailbox server hosting an active organization mailbox. Method 2: Restart the Mailbox Assistant service. The Microsoft Exchange Mailbox Assistant service on Mailbox Role is responsible for generating OAB. Restarting this service generates all OAB’s defined in the environment on a specific mailbox server, if it’s hosting an active organization mailbox. Placement of Organization Mailbox Exchange Server 2013 CAS role proxies the OAB download request to a “nearest” mailbox server hosting an active Organization Mailbox. It can proxy the request in round robin fashion if it finds more than one organization mailbox active in same AD site. Prior to CU5, this will result in frequent full OAB downloads and is therefore, not recommended. Hence, current guidance is to plan organization mailbox placement such that you will have one organization mailbox active in an AD site. This applies to creating a new organization mailbox as well as to creating copies of mailbox database that hosts an organization mailbox. Prior to CU5, customers should only deploy a single OAB generation mailbox per Exchange organization to prevent users from accessing different OAB generation mailboxes and requiring a full OAB download. With CU5 and later, customers can assign OABs to specific OAB generation mailboxes and not have to worry about accidentally triggering full OAB downloads due to accessing different OAB generation mailboxes. For more information, please see the article, OAB Improvements in Exchange 2013 Cumulative Update 5. Scenarios The following scenarios discuss a real life situation to further explain the new OAB management methods. Scenario 1: Create a new Organization Mailbox Contoso has Exchange Server 2013 Mailbox & CAS role servers deployed at Dallas and Seattle sites. John, the Exchange Admin for Contoso, analyzes the http proxy log files on CAS servers and finds the OAB download request for Seattle users is going to Dallas servers. On further investigation, John finds he has just one Organization Mailbox present in Dallas, hence OAB download requests of all the users are going to Dallas server. He decides to create a new Organization Mailbox at Seattle site with following commands: Step1: Create a new Arbitration Mailbox New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB Mailbox for Seattle” Step2: Enable the Arbitration Mailbox with OABGen capability Set-Mailbox -Arbitration oabs -OABGen $true -MaxSendSize 1GB Scenario 2: Customize OAB Generation Schedule Ben is an administrator of Exchange 2013 deployment at Tail Spin Toys. The default OAB generation schedule does not suit them and they want to generate OAB approximately every fourth hour of the day. Ben will use following command to change properties of the mailbox servers that will be hosting the Organization Mailbox. Set-MailboxServer Exch1 -OABGeneratorWorkCycle 01.00:00:00 -OABGeneratorWorkCycleCheckpoint 04:00:00 After a couple of days, John analyzes Event ID 17002 in application log and makes sure the OAB is generated every four hours. Hopefully, you find this post useful! Let us know your feedback below! Bhalchandra Atre Updates 5/15/14: Updated Placement of Organization Mailbox section to align with current guidance.Custom (aka. Extension) attributes in Exchange 2010 SP2 (and later) and their use
Some of sharper readers of our documentation talking about schema changes that Exchange makes (see Exchange Server Active Directory Schema Changes Reference, November 2011) have noticed that in Exchange 2010 SP2, we have added several things that sound very related to what’s traditionally known as “custom attributes” in Exchange. Specifically: For object class ms-Exch-Custom-Attributes we added: ms-Exch-Extension-Attribute-16 to 45 ms-exch-extension-custom-attribute-1 to 5 There have been some questions regarding this; namely – are all of those for you to use? Does this mean that you now have all of those attributes to modify to your heart’s content? What’s the difference between all those things anyway? Here’s the scoop: For a while now, Exchange provides 15 custom attributes. Those are still there and you are free to use them as you used them before. They are known as CustomAttribute1 to 15 (or can also be referred to as ms-Exch-Extension-Attribute1 to 15). For more on those, please see this. So nothing has changed with those. New! In Exchange 2010 SP2, we have added five new multi-value custom attributes that you can use to store information for mail recipient objects. They are the ExtensionCustomAttribute1 to 5 (also can be referred to as ms-exch-extension-custom-attribute-1 to 5). For the list of CMDlets that support those, please see this. New! Finally, we have also added ms-Exch-Extension-Attribute-16 to 45. Those are not exposed to various CMDlets and Exchange management UI, because they were added for future use. As such, we cannot recommend that you use non-Exchange tools to edit their values (Exchange 2010 SP2 or any later version) because we might use those attributes in the future for various Exchange features. If and when we add management tools access to them, we will definitely let you know! Nino BilicConsidering updating your Domain functional level from Windows 2003? Read this!
Now that Windows Server 2003 end of life (July 14 th , 2015) is on the horizon, many customers are updating their Active Directory (AD) Domain Controllers (DC) from 2003. The first item to consider is which Windows Server Operating System (OS) you will be moving to for your DC’s. There are several options to consider today: 2008, 2008R2, 2012, or 2012R2 operating systems. However, no matter which newer OS you move your DC’s to, coming from 2003, the krbtgt account will reset its’ password when you update the Domain Functional Level (DFL), which is the concern that could break Exchange. Note: If your DFL is already set to 2008 or higher, then you do not need to worry about this article. It is a good idea to know that during the process of raising the Domain Functional Level (DFL) of your Active Directory structure from 2003, the krbtgt account password gets changed. This password replication is a separate change within AD and occurs after the DFL has been raised. This change should have no impact on any applications that depend on Active Directory, but sometimes it does cause applications to stop authenticating, one of them being Exchange. Since raising functional levels is an irreversible operation (in many situations, but not always anymore), it should be planned with care and only after having verified that it will not impact any applications that rely heavily on Directory Services. Mostly any in-house written and/or third party products are the main concern. A lab environment for testing the applications would be the best option, which is why we recommend a lab for Exchange. After you’ve made the DFL change from 2003, then you’ll want to watch for any Event ID 14 or Event ID 10 errors in the System Event Viewer on the DC’s. If you do see these events appear after the DFL has been raised, then there are a couple of options available to resolve the authentication error. Option 1: Restart the Kerberos Key Distribution Center service on all DC’s (short impact, service restart) Command line option steps: SC \\ComputerName Stop kdc SC \\ComputerName Start kdc Active Directory PowerShell module steps: $DC=Get-ADDomainController Get-Service KDC –ComputerName $DC | Restart-Service GUI steps: Open the Services mmc (services.msc) on the DC’s Select the Kerberos Key Distribution Center service and click the restart button Option 2: Restart all DC’s in the Forest (greatest impact, restarting of servers could take time) Manually log into each DC and restart them all, OR Within the Active Directory PowerShell module: $DC=Get-ADDomainController Restart-Computer $DC Why is this important? While there should be zero impact to applications, the fact that the krbtgt account password does get reset and it could impact the speed in which Exchange (or other applications) waits for that accounts’ password to be updated via the normal AD replication process. We are recommending that you know how to perform the given resolution steps and that you do this change during a change notification process. Why does this happen only during the 2003 DFL change? The underlying issue is due to the addition of the AES hashes (128 and 256) introduced. The changes only add the AES hashes during the one DFL change from 2003 to any higher level (’08, ‘08R2, ’12, ‘12R2) domain functional level. The potential to implement other newer/updated encryption types in future OS versions does exist and we once again could run into this issue. Knowing is half the battle. It is very unlikely that you’ll run into this issue, but now that you know how to solve it and be prepared IF you run into it, you now have easy and quick solutions at the ready. Plan your change, move up to the newer version OS/AD functional levels, enjoy the new features that are available today, and don’t let this change break Exchange. Mike O'Neill
