Managing 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.Triaging Exchange Performance issues related to Active Directory (AD) Performance (including Networking and DNS performance)
In many organizations the skill sets that administer Exchange, Active Directory (AD), Domain Naming System (DNS), and the network infrastructure are often segregated. Since Exchange is heavily dependent on communication with AD and that communication must traverse the network, the ability for the Exchange Administrator to have a basic understanding of how each of these components can be troubleshot is useful. Furthermore, often times the DNS, network, and AD administrators are not familiar with how Exchange is dependent on their services and thus are not fully prepared to help an Exchange administrator isolate production issues. As such, by the end of this it is hoped that there will be enough information to allow the Exchange, DNS, network, and AD administrators to each collect the data necessary to identify the majority of the issues. There is some required reading that is necessary in order to understand much of the content that follows. Rather than reiterate all of the pre-requisite knowledge here, reviewing the following content might be helpful: Ruling Out Active Directory-Bound Problems Monitoring Without System Center Operations Manager: Exchange 2007 Help Most specifically - Monitoring Common Counters: Exchange 2007 Help Why you need Active Directory for Exchange Server 2007 Measuring AD Performance Understanding and Troubleshooting Directory Access Exchange Server 2003 and Active Directory Mike Lagase : New ADAccess Performance counters included with Exchange 2007 SP2 Performance Tuning Guidelines for Windows Server 2003 Performance Tuning Guidelines for Windows Server 2008 Microsoft® Windows ServerT 2003 Resource Kit To start with, an understanding of what the performance counters "LDAP Read Time" and "LDAP Search Time" track is very useful (as identified in Ruling Out Active Directory-Bound Problems and Monitoring Common Counters: Exchange 2007 Help). One knows that once these counters approach or exceed the recommended thresholds, troubleshooting outside of Exchange needs to begin. Therefore, the question, "What are the potential contributors to high values for these counters?" is thus raised. Since these counters are installed with Exchange and are tracked within the DSAccess /ADAccess components, depending on the version of Exchange, there are a number of dependencies that Exchange does not have visibility into that the troubleshooter needs to be cognizant of when evaluating where the source of the delay is incurred. In order to provide a clearer picture of what needs to be considered, below is a walkthrough of a somewhat simplified list of events that happens after the clock starts ticking (reference How Active Directory Searches Work for greater detail): 1. WLDAP32.DLL receives the request from one of the Exchange processes. It has to locate a Global Catalog (GC) first. 2. DNS query traverses the network. Unresponsiveness or degraded responsiveness from DNS servers will degrade the overall performance of the query. 3. WLDAP32.DLL submits the query to the GC. 4. If not already started, a Transmission Control Protocol (TCP) session is established, the Lightweight Directory Access Protocol (LDAP) query traverses the wire. Note: since TCP requires a 3 stage handshake before the session and in turn windowing can work, multiply network latencies by 3 to figure out how much time it takes just to establish the session (thus that 10 ms latency becomes 30 ms delay even before the Exchange server submits the query). 5. The TCP data transmitted up the networking stack to LSASS.exe listening on the LDAP ports. 6. The query is processed by the GC and searches through the database to return the results. 7. The data is sent out the Network Interface Card (NIC) on the GC. 8. The query is received via WLDAP32.DLL from the GC. a. If there are multiple pages all pages need to be returned and stored in a data structure within DSAccess / ADAccess. Each of these requires traversal of the network and resubmission of the query. b. If there are a large quantity of values in the requested attribute (think group memberships), these all need to be retrieved and returned. This results in multiple queries to the GC. This may require steps 1 - 5 to recur. As can be seen from the above set of steps a lot of the performance delays are heavily dependent on network latency and network performance. In fact the only portion of that number that is actually impacted by the GC performance itself is step 5. As such, in addition to troubleshooting any potential performance issues on the GC, it is highly advantageous to collect network trace data when issues do occur, preferably from both sides of the conversation. Summary of Data needed to troubleshoot Exchange Server - Having this data from both sides is important for comparison purposes (i.e. is the processor spike on the DC correlating with the degraded performance in Exchange) Performance Counters specified in the referenced articles: Exchange 2007/2010 - Monitoring Common Counters: Exchange 2007 Help Exchange 2000/Exchange 2003 - Ruling Out Active Directory-Bound Problems Note: For Exchange 2003 add in MSExchangeDSAccess Domain Controllers\LDAP Sea rch Time(All Instances) and MSExchangeDSAccess Domain Controllers\LDAP Read Time\(All Instances) so that the DC to be troubleshot can be identified. Network Trace from the Exchange server side Note: To ease collection of the Exchange performance data reference "Mike Lagase : Perfwiz replacement for Exchange 2007" AD Server - Performance Data - Windows 2008/2008 R2 - Monitoring Common Counters: Exchange 2007 Help recommends starting the built in Data Collector Set "Reliability and Performance\Reports\System\Active Directory Diagnostics" and use the data collector set. Reference: Performance Logs and Alerts Windows 2003 At a minimum, the counters specified in Ruling Out Active Directory-Bound Problems SPA - Select the Active Directory report. Network Trace from the affected DC side. DNS Server - not all organizations use Microsoft DNS servers, but for the purposes of this article the assumption that a Microsoft DNS server is in use. Network Trace from the DNS server Performance Data Windows 2008/2008 R2 - start the built in Data Collector Set "Reliability and Performance\Reports\System\System Performance" and use the data collector set. Windows 2003 - SPA Select the System Overview report Performance counters - All DNS related counters. How to triage where troubleshooting needs to happen Network Infrastructure issues - Use the network trace to determine if the DNS server is responding in a timely fashion. Keeping in mind that Microsoft recommends the entire conversation happen in less than 50 ms in general, if the DNS servers are taking more of that 50 ms than the actual LDAP search, this could be problematic. Timely is also subjective to whatever is normal for the environment and base lining is helpful here. In general if the DNS server is on the same segment and performing properly, 1 to 2 ms or less is reasonable. Of course as always, it is recommended that the environment be base lined so that the expected performance is known. Use the network trace to determine if the TCP session with the GC is being established in a timely fashion. Again, keeping in mind that there is a 50 ms performance threshold, if the TCP session establishment is taking more time than the actual LDAP search takes to complete, this could be problematic. Also, timely is also subjective to whatever is normal for the environment and base lining is helpful hear. In general, if the GCs are on the same segments and both the network and the GC are performing properly, sessions established in 1 to 2 ms or less is reasonable. Of course as always, it is recommended that the environment be base lined so that the expected performance is known. AD Issues - Often AD infrastructures are large and the AD admins cannot determine which of the many GCs is in use by the affected Exchange server, thus the responsibility of pointing the AD support team to the right box to troubleshoot falls on the Exchange admin. Use the network trace to find out which GC is having a large delay between the LDAP Request and LDAP Response packets. Use the performance counters to narrow down to the box that is performing poorly. Exchange 2007/2010 - MSExchange ADAccess Domain Controllers\LDAP Search Time and MSExchange ADAccess Domain Controllers\LDAP Read Time check the specific instances for values exceeding the recommended thresholds. This will report the specific GC (and underlying network path) that is not responding to Exchange as quickly as desired. Note: On Exchange 2007 SP2 and newer systems, the "MSExchange ADAccess Local Site Domain Controllers" can also be used in the same manner. Exchange 2003 - MSExchangeDSAccess Domain Controllers\LDAP Search Time and MSExchangeDSAccess Domain Controllers\LDAP Read Time, check the specific instances for values exceeding the recommended thresholds. This will report the specific GC (and underlying network path) that is not responding to Exchange as quickly as desired. Exchange 2000 - performance counters similar to the above did not exist. The only way to determine which GC is responding slowly is to analyze a network trace as described previously. Next, identify bottlenecks within the GC (note: for the most part these basics apply to troubleshooting DNS performance as well): While there are a large variety of potential issues, there are some basic things that can be eliminated before advanced troubleshooting need take place. The below guidance are the most basic remediation suggestions for the largest variety of these types of issues. Essentially this comes down to, "Ok, so the issue is identified, now what do I do?" Since there is plenty of published information on how to isolate disk, processor, and/or network issues, please reference the excellent articles linked at the beginning for the recommended thresholds. Also, check out Performance Analysis of Logs (PAL), which automates the analysis of the performance data collected to help determine where the system is bottlenecking. Disk bound - Once the issue is isolated to being disk bound, there are essentially two options, add memory or allow for increased disk IO (i.e. add spindles for direct attached storage). Adding memory is not quite as cut and dry as just throwing in some sticks of RAM. 32-bit systems - It makes sense to avoid rehashing the entire discussion of 32-bit OS architecture especially since 32-bit architecture is on its way out. Reference this support article for some useful info. Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server 64-bit systems - Generally the easiest thing to do is to put enough RAM in the box to load the entire database (minus white space) in memory. As of this writing, even for the largest enterprises (16 GB to 32 GB databases), this is becoming quite inexpensive or easy to justify. If the box has enough memory to load the entire database already and disk IO is the issue, troubleshoot why the database is not being loaded. A couple tip: Measure Process\Virtual Bytes\lsass to see if it is about (within 10%/20%) of the size of the database (minus white space) or larger. If it isn't, troubleshoot why lsass isn't growing. Ensure that other applications aren't consuming large amounts of memory and preventing LSASS from growin g like it wants to. Increasing disk-throughput. If RAM cannot be added (or additional RAM will provide no benefit) due to the limits of the 32-bit OS architecture migrate to 64-bit. If migrating to 64-bit is not an option, the only option left is to add more disk throughput. Assuming that the storage is local and not SAN attached, it essentially means add more spindles (talk to the SAN guys if the AD database is stored on the SAN). Reducing disk IO to the database volume is another option. Look at options such as turning off backups and AV scans during production hours, move SYSVOL and/or the database logs to separate spindles. Just follow standard storage performance tuning recommendations. Also, IOs to the disk can be reduced by reducing the demand on the boxes either by adding more DCs to the environment or reducing client demand. SPA and Performance Logs and Alerts will help track down what else is using the volume. Processor bound: Ensure that LSASS is the process using the CPU, if not eliminate the problematic process. If LSASS is running hot, then use SPA (Windows 2003) or Performance Logs and Alerts (Windows 2008 and up) to identify where the CPU is being consumed within LSASS. If everything looks normal then the only option remaining is to add more processors to the box or more boxes to the infrastructure if there is high processor load across multiple systems. Note: In large infrastructures with multiple DCs and multiple Exchange servers, adding more hardware only makes sense if all of the boxes are experiencing high CPU utilization (close to or exceeding the thresholds in Ruling Out Active Directory-Bound Problems). If most or all of the boxes in the Exchange site are not experiencing high CPU utilization then there is probably a system specific reason for high CPU time. Look for hardcoded applications, improperly balanced load due to tuning LDAP Weights and Priorities (Check out Why you need Active Directory for Exchange Server 2007 for details on how this works), or anything else which may indicate why on GC is being singled out compared to the rest. Fix that issue before adding more hardware. Network: If the outbound queue length is > 0 sustained the easy fixes are: Update the NIC drivers to the latest versions if possible Disable the Scalable Networking pack features (SNP) on Windows 2003 base servers- An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers. Check the network card settings to see if your driver can enable or disable certain SNP offloading features. Depending on the driver, if you disable these settings at the OS level, there is a possibility that they can still be enabled directly on the network card settings. If the DCs are running Windows 2003 and the Exchange Servers are running on Windows 2008, then apply the Scalable Networking Pack rollup on the DCs to ensure that known compatibility issues do not occur. Also be aware of a known Windows 2008 TCP/IP setting issue in http://support.microsoft.com/kb/967224 that can affect overall network connectivity and performance. Ensure that the NIC speed/duplex settings are properly set. MS recommendations, as of this writing, recommend both the GC and switch be set to 100/Full for 100 Mb segments and Auto/Auto for GigE segments. Check the Network Interface\Current Bandwidth performance counter to ensure that network card auto-negotiation is not changing the speeds the network card. This value should remain consistent at one value throughout the lifetime of the server being online. Disable the load balancing/fault tolerance features of the NIC driver suite. Ensure that Network Interface\Packets Outbound Errors performance counters remains at 0 all the time. Any increases in this value can indicate intermittent connectivity issues on the server. If the network connection is using more 60% to 80% of the maximum bandwidth, the only solutions are to upgrade the available bandwidth (100Mb > GigE) or distribute the load across multiple servers/network connections. Identifying the source of the GC load The possibility exists that, despite the DC being either disk or processor bound, that the load is unnecessary. To determine this, the load on the box must be analyzed in greater detail than just the performance can provide. To that end, there are two main strategies for identifying the load on the box, both of which can be used concurrently. How to analyze this data is somewhat out of scope of this article, but the below bullets contain links to useful articles on how to use this data: Enable diagnostic logging on the DC by setting the "15 Field Engineering" registry value in order to identify expensive queries that return greater than 1,000 objects. For more details on how to use this reference: Logging LDAP searches: AD and ADAM > ActiveDir.org Creating More Efficient Microsoft Active Directory-Enabled Applications Pros Shows the expensive or inefficient LDAP queries The data is easy to get to since it is stored in the DS log Data collection and alerting can be automated using SCOM. Cons Can overwrite the logs quickly, but the irony here is that if it is flushing the logs quickly, there is probably a lot of expensive queries that need to be remediated. Doesn't actually track the processor impact of the query. Only reports on LDAP queries. Use SPA (note this functionality exists natively in Windows 2008 and is entitled Performance Logs and Alerts which is part of Windows Reliability and Performance Monitor) More details Brad Rutkowski's Blog : Great tool for Windows 2003: Server Performance Advisor (SPA) Download details: Microsoft ® Windows Server T 2003 Performance Advisor Brad Rutkowski's Blog : Interacting with Data Collector Sets via Powershell tonymurray : Troubleshooting LDAP issues with Server Performance Advisor (SPA) Tracking LDAP Searches with Windows Server 2008 Reliability and Performance Monitor > ActiveDir.org Pros Shows everything that is going on, whether it is authentication, LDAP queries, network traffic, or disk IO. Data collection can be triggered using SCOM when certain thresholds are hit. Cons On busy DCs the logging can quickly grow to unmanageable levels (busy being hundreds of LDAP queries and authentications per second). Think on the order of 100+ MB per minute. But this isn't too bad as usually a 5 to 10 minute data collection during a production issue will get the data necessary to identify what is occurring. Requires the installation of a tool set (Windows 2003 only) Conclusion Data collection is key! Getting the right data when the problem occurs is absolutely critical to the restoring the health of the environment. Furthermore, as Exchange is the product suffering when its dependencies are not responding adequately, it falls on the Exchange administrator to do the leg work collecting the right data from the perspective of Exchange, and then isolating where the network, DNS, and AD administrators might need to look and start collecting data. Without this information, the network, DNS, and AD admins will be looking for a needle in a haystack and it is highly unlikely that they will find anything of use. Thus, once the Exchange admin has isolated the dependencies of concern, using the information provided here, it will be much easier to collect the data necessary from those systems to remediate any issues. Thanks to Rod Fournier and Mike Lagase for their endless suggestions for improvement of this blog post. - Ken BrumfieldADModify.NET is here!
A quick intro to ADModify: ADModify is a tool that was (and is still) developed and maintaned out of our Support Services (aka PSS) team, and was created to make it easier to modify / import / export objects in Active Directory in bulk. The tool has been available on the FTP site for download for a while, but with recent release of new version (ADModify.NET or v2.0) - we have decided to create a gotdotnet workspace for it too to make it easier for you to give us feedback on it :) So - recently, Marc and I have released ADModify.NET. ADModify.NET (v2.0) was written from the ground up using Visual C# .NET 2003. When benchmarked against its predecessor, it made the same modifications in less than half the time. Its new feature set allows administrators to bulk modify any AD attribute from any AD partition with almost limitless flexibility. Administrators will also find that they are no longer restricted by the attributes hard coded into the tool, as ADModify now contains the ability to modify any attribute just simply given its name and value. ADModify is also no longer restricted to literal values; it is now possible to dynamically build values based off of current AD attributes. Logging and Error handling has also improved dramatically. All logging is now done using XML, making it much easier for administrators to manipulate and store the data and even take advantage of features such as Undo. Keeping with the Windows 2003 initiative that everything that can be done in the GUI should be available via command line, a command line version of the tool that contains all of the same features is included as well. It is worth noting that ADModify.NET requires the .NET Framework. It also is worth noting that it will not run across a network drive. Here is the download point: http://www.codeplex.com/admodify The rest of this blog covers the major new features that are available in ADModify.NET over the old version ADModify 1.6. Terminal Server Attributes It is now possible to modify Terminal Server attributes using ADModify.NET. All TS attributes that are available in the Windows 2003 Active Directory Users and Computers users property page are available. ADModify utilizes the TSUserExLib Library, so Windows 2003 or later is required to make Terminal Server setting modifications. You do not have to be running a Windows 2003 domain; you will just simply need to run the program from a Windows 2003 Server for this specific functionality. Mailbox Rights Mailbox Rights are also now available for bulk modification. There are 4 options when dealing with mailbox rights: - Dump Mailbox Rights - Import Mailbox Rights - Bulk Add a User to Mailbox Rights - Bulk Remove a User From Mailbox Rights Since CDOEXM is utilized, Exchange 2000 or later ESM must be installed on the machine that ADModify.NET is run on to be supported. Dump Mailbox Rights This option will export all of the ACE's in a users mailbox rights to an XML file, separated by inherited and non-inherited rights. This file can be used as a way for administrators to track mailbox rights and can also be used to import. Undo is not supported when using this option, as it is a read only operation. Import Mailbox Rights As long as a valid export of mailbox rights has been completed, the Import Mailbox Rights option can be used to import them. All that is required is a valid mbxrights.xml file. Undo is also not supported here. Bulk Add a User to Mailbox Rights With this option it is possible to add a user with specific rights to multiple mailboxes at the same time. For example, you could grant the user DOM\user1 Full Mailbox Access to a specific subset of users with relative ease. Undo for this operation is supported. Bulk Remove a User From Mailbox Rights Same as the Bulk Add option except this option will remove the specified user from mailbox rights. Undo for this operation is supported. Name that attribute! Possibly the most robust new feature of ADModify is the flexibility to simply name the attribute you wish to modify. Any attribute that contains a string, Boolean (true/false), or integer value can be modified in this fashion (attributes that contain data types such as SIDs and Long Integer are not supported). In here, simply fill in the attribute name and value. For multivalued operations, be sure to choose append or remove. The reason is simply this: if you modify a multivalued attribute and do not choose the multivalued option, the attribute will be overwritten with the new value, not appended. Using Variables Administrators are no longer restricted to using literal values when bulk modifying users. ADModify now supports the use of variables. What are variables? They simply allow you build a value for an attribute based off of one or more current attributes. The syntax is simple. Simply enclose the value in single ticks (') to treat it as a variable. If you wish to build an attribute using both variables and literal values, just remember that variables need to be separated from literal values using the percent sign (%). You can also take the first x number of characters from an attribute and use that as well. Example: Syntax for using the description attribute as your value: 'description' Syntax for using two attributes, givenName and sn (separated by a space): %'givenName'% %'sn'% Syntax for using multiple attributes and literal values: h:\homefolders\%'sAMAccountName'%\%'givenName'%\ Syntax for taking the first character of an attribute: %1'givenName'%.%'sn'%@microsoft.com If the need should arise to actually use the % or ' characters in an attribute value, simply use a preceding forward slash as an escape character. You can mix variables with literal values, even the % and ' characters as long as the correct syntax is used. Example: To assign the value "This is a percent sign: %", use this: This is a percent sign: /% To assign the value "My username is 'username' " (where username is the sAMAccountName), use this: My username is /'%'sAMAccountName'%/' Undo Feature Administrators need no longer fear making massive bulk updates to AD Users. With the exception of the "Remove Exchange Attributes" and "Import Mailbox Rights" options, every modification is undo-able. All modifications are written to a log file named after the current date and time, in MMDDYYYYHHMMSS.xml format. All modifications will not only log the new value, but the user’s previous value. As long as the log file is in tact, ADModify.NET can parse it and undo the changes that were previously done. In addition to the changes that were made being logged to the XML file, there is also an undo.log file. This file contains all users processed by undo and logs skipped users, the reason for the user being skipped, and a summary of changes. Command Line syntax: admodcmd -undo filename.xml admodcmd - ADModify.NET in Command Line admodcmd.exe is a fully functional command line version of ADModify.NET. Syntax can be obtained using admodcmd -?. However, below you will find some examples for common administrative tasks. 1. Adding a secondary SMTP address of firstinitial.lastname@company.com admodcmd -dn OU= MyOU , DC =domain,DC=com -addsmtp %1'givenName'%.%'sn'%@company.com 2. Name the attribute you wish to modify Modify the description field to contain the value "My legacyExchangeDN is (legacyExchangeDN)", where (legacyExchangeDN) is the users legacyExchangeDN: admodcmd -dn OU= MyOU , DC =domain,DC=com -custom description "My legacyExchangeDN is %'legacyExchangeDN'%" 3. Modify the display name to read last name, first name admodcmd -dn OU= MyOU , DC =domain,DC=com -custom displayName "%'sn'%, %'givenName'%" 4. Modify the users Relative Distinguished Name (CN) from firstname lastname to lastname, firstname admodcmd -dn OU= MyOU , DC =domain,DC=com -modrdn "%'sn'%, %'givenName'%" These are just a few of the examples. For more sample usage on admodcmd, consult the ADModify.NET help. - Dan WinterAssigning "Send As" Permissions to a user
It was brought to my attention that following the steps listed in KB327000 (http://support.microsoft.com/?kbid=327000), which applies to Exchange 2000 and 2003, to assign a user "Send As" permission as another user did not appear to work. I too tried to follow the steps and found that they did not work. I know this feature works, so I went looking around for other documentation on this and found KB281208 (http://support.microsoft.com/?kbid=281208) which applies to Exchange 5.5 and 2000. Following the steps in KB281208 properly gave an user "Send As" permission as another user. But I found the steps listed in KB281208 were not complete either. The additional step that I performed was to remove all other permissions other than "Send As". Here are the modified steps for KB281208 that I performed (changes noted in blue): 1. Start Active Directory Users and Computers; click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers. 2. On the View menu, make sure that Advanced Features is selected. 3. Double-click the user that you want to grant send as rights for, and then click the Security tab. 4. Click Add, click the user that you want to give send as rights to, and then check send as under allow in the Permissions area. 4.5 Remove all other permissions granted by default so only the send as permission is granted. 5. Click OK to close the dialog box. So after I verified that the steps for KB281208 worked, I was curious as to why the steps for KB327000 did not work. What I found was that Step #7 of KB327000 applied to the permission to "User Objects" instead of "This Object Only". Here are the modified steps for KB327000 that I performed: 1. On an Exchange computer, click Start, point to Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers. 2. On the View menu, click to select Advanced Features. 3. Expand Users, right-click the MailboxOwner object where you want to grant the permission, and then click Properties. 4. Click the Security tab, and then click Advanced. 5. In the Access Control Settings for MailboxOwner dialog box, click Add. 6. In the Select User, Computer, or Group dialog box, click the user account or the group that you want to grant "Send as" permissions to, and then click OK. 7. In the Permission Entry for MailboxOwner dialog box, click This Object Only in the Apply onto list. 8. In the Permissions list, locate Send As, and then click to select the Allow check box. 9. Click OK three times to close the dialog boxes. The KB articles were updated to include correct information. But, if you had problems with this in the past, this might be why! - Chris AhlersExploring Exchange 2010 RPC Client Access service
In Exchange 2007, we introduced five server roles that performed distinct functions within the Exchange organization. One role in particular - the Client Access server role - introduced a variety of new Web services, including the Availability service, the Autodiscover service and Calendar Concierge services. In Exchange 2010, we have the same five server roles. However, there are some significant architectural changes and some shift in responsibilities. In this blog, I focus on the Client Access server role and go into detail about some of its architectural changes. Perhaps the most significant change is that, in Exchange 2010, two new services on CAS called the RPC Client Access and Address Book services establish the RPC endpoint for MAPI, NSPI and RFR client access. This new functionality replaces the RPC endpoints in the Information Store. The RPC endpoint in the Information Store has not been removed in Exchange 2010, but it has been modified to only accept requests from CAS servers. The RPC endpoint for public folder database access remains on the Mailbox server, however, Outlook clients now communicate directly with the RPC Client Access service on the Mailbox Server for public folder database access, and not with the Information Store. Background In Exchange 2003, all clients either connect directly to the Information Store for data access and data rendering, or through front-end servers that proxy communications to the Information Store for data access. In Exchange 2007, we started to consolidate data access paths, so that most clients (for example, OWA, Exchange Web Services, POP and IMAP), all went through a common business logic layer known as the Exchange middle tier. The middle tier is a library that is built into all of the server roles. Clients that went through this common business logic layer were able to take advantage of consistent business logic for their operations. At this point, MAPI clients (such as Outlook) and WebDAV clients (such as Entourage 2004) still connected directly to the Information Store. In Exchange 2010, new managed-code RPC end-points were introduced in the CAS role that sit on top of the core business logic layer shared by the other internal Exchange server roles. In addition, WebDAV has been removed. This of course means that applications that use WebDAV need to be updated or migrated to versions that support Exchange Web Services. Below is a comparison of the data access paths in Exchange 2007 and Exchange 2010: Exchange 2010 Middle Tier In order to facilitate this move to the middle tier, two new services were created that run on the Client Access Server role: the RPC Client Access service and the Address Book service. The RPC Client Access service handles all data connections for mailboxes and the Address Book Service handles all data connections for access to Active Directory. One notable exception is public folders. For public folder connections, clients connect to the RPC Client Access service on the Mailbox role, and not the Information Store. RPC Client Access service In Exchange 2007 and earlier, MAPI clients connect directly to the Mailbox server. This meant when failover of a clustered mailbox server occurred, clients were disconnected from their MAPI and directory endpoints. In Exchange 2010, we have abstracted the client connection away from the Mailbox server. Thus, when a mailbox database switchover or failover occurs, clients remain connected to their MAPI and directory endpoints. This provides a more seamless experience for Outlook clients. Achieving seamless switchovers and failovers was one of the main motivators for moving these endpoints to the CAS role. By abstracting the client connection away from the Information Store, when some kind of failure occurs to the database containing a user's mailbox, Outlook doesn't necessarily need to reconnect or restart. Another huge benefit is the ability for all clients to use the same code and logic to access the store and for content and body conversion. This means that whether the client is coming through IMAP, MAPI or if someone's making a Web-based connection using OWA, we no longer have to be concerned about the business logic manipulating data into a format that other clients might not be able to read. This is done to mitigate issues like MIME to MAPI conversion. Additionally, this simplifies the Information Store process by making it leaner. RPC Client Access Array When a Client Access server communicates with the Mailbox server, it makes sense to view it as the Client Access server communicating with the Mailbox database via the Mailbox server that hosts the database. This is especially evident in a load-balanced array of Client Access servers and/or where your environment is configured to use Database Availability Groups that are associated with a Client Access server or Client Access server array. In a non-load balanced environment, the mailbox database is associated with only a single Client Access server. In a load-balanced environment, the Mailbox database is associated with the load balanced array of multiple Client Access servers. When you start adding two or more Client Access servers, you take advantage of the RPC Client Access Array feature. By default, before a Client Access array is configured, all databases are associated with a Client Access server in the environment and the Outlook clients communicate directly with the Client Access server until the association with the database is updated to be the Client Access array. In order for the clients to utilize a CAS array, by default, a CAS array should be created ahead of time. Below is an overview of these steps: Create a Client Access array utilizing a unique FQDN. Add the Client Access servers within the AD site to a load balanced array and in DNS associate the unique FQDN to the Virtual IP of the load-balanced array. Configure the databases to utilize the CAS array. New-ClientAccessArray –FQDN <RPCClientAccess ArrayName> –Site <SiteName> The New-ClientAccessArray cmdlet is used to create a new Client Access array. This creates an object that represents a load balanced array of Client Access servers within a single Active Directory site as shown below. The networkAddress attribute corresponds to the FQDN of the array. From this point on, any new mailbox database that are created in the environment (in this same site) will be associated with this array. The database creation process pulls the value of the networkAddress attribute from the Array object in Active Directory and assigns it to the database's RPCClientAccessServer attribute. Associating the CAS Array with a Mailbox Database Each mailbox database object has an attribute called RpcClientAccessServer. The information contained in this attribute is what point's clients to the MAPI end-point they should be using. If you have more than one database, you will see multiple listings and the RpcClientAccessServer value could be different servers. Use the following command to associate a database with a Client Access server or Client Access array: Set-MailboxDatabase <Database_name> -RpcClientAccessServer <ClientAccess ServerName or ClientAccess-ArrayName> This command changes the legacyExchangeDN attribute of the Mailbox Database. The value is stored in the following location: CN=Mailbox Database ##########,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com After changing the value stored in this attribute, the client knows the location of the RPC endpoint for the array. Note: Before the Set-MailboxDatabase cmdlet is executed, the attribute is set to one of the Client Access servers in the environment in the same site. To determine the end point that clients will use for access to this database, Exchange first checks if there is a CAS array in the local site. If there is, it will use the array; the RPCClientAcessServer attribute would be set to the FQDN of the array. If an array does not exist, Exchange will determine if the server hosting the database is also a CAS. If it is a CAS, Exchange will use it. If the server hosting the mailbox database is not also a CAS, Exchange will pick a random CAS from the site containing the user's mailbox. In order to find the MAPI endpoint for mailboxes, Exchange queries AD for the HomeMDB value of the user, as well as the name of the user's mailbox database. The legacyExchangeDN for the user's mailbox database is also retrieved. This value is the endpoint that Autodiscover will give to the client, and that the client should use to connect to the user's mailbox. RPC Client Access in a High Availability Scenario In an environment with a DAG and an NLB CAS Array, Active Manager always keeps track of which database is active. Active Manager reports this information to servers in the CAS array. Because of this, the Outlook client does not have to keep track of this and continues to only communicate with the Client Access array. In case of a failure at the mailbox and/or at CAS level, the client should regain data access within 30 seconds. Address Book Service Prior to Exchange 2010, Exchange Server included a referral service that told Outlook clients where to find the Name Service Provider Interface (NSPI) endpoint. This referral usually pointed Outlook to a Global Catalog server (although Outlook Anywhere connections would leverage the mailbox servers as a proxy for Global Catalog functions). This functionality was provided by a component called Directory Services Proxy (DSProxy). Outlook expects to find this referral service on the same server that it is using for MAPI access. When Outlook contacts the Client Access server, two possible actions happen: If the user's mailbox is on an Exchange 2010 Mailbox server, then either: If the user's mailbox is in the same site as the Client Access server, the local Client Access server or local CAS array is used; or If the user's mailbox is in a different site, the request is referred to a Client Access server in the remote site or a remote CAS array. If the user's mailbox has been moved back to a legacy Exchange Mailbox server, the directory request is referred to the user's mailbox server. Existing legacy mailboxes don't talk to Exchange 2010 CAS servers for directory information. Note: If a mailbox is moved back to 2003/2007, CAS will redirect the client to the legacy Mailbox server which will provide a referral to a Global Catalog server. Otherwise, all legacy mailboxes are unchanged This also acts as a simplified solution for finding a writable domain controller and a unified solution for GAL access. A representation of the directory access path in Exchange 2010 is shown below: RPC Encryption Settings By default, Exchange 2010 requires encryption for RPC client access. This means that by default, Outlook 2003 clients will not be able to connect to Exchange. To enable connectivity, we recommend enabling encryption for Outlook 2003, and not disabling encryption on the server. For more information about this issue, including workarounds, see Outlook Connection Issues with Exchange 2010 Mailboxes In addition to the RPC encryption requirement, UDP notification support was removed from Exchange2010. As a result, Outlook 2003 clients in Online Mode can only use polling notifications. This will result in a slight delay in updates to item status (30 seconds on average, with up to a one-minute delay) when changes are made to items in a mailbox accessed by Outlook 2003. There are two workarounds for this issue: Use Outlook 2003 in Cached Exchange Mode; or Adjust the polling interval on the Client Access server. This will impact the performance of the Client Access server. For more information about this issue, see In Outlook 2003, e-mail messages take a long time to send and receive when you use an Exchange 2010 mailbox and Common Client Access Considerations for Outlook 2003 and Exchange 2010 Benefits of RPC Client Access The goal in Exchange 2010 was to make the store leaner and really more of a data store than a factory for the client business logic. We've been able to move quite a bit of business logic out of the store by removing many of the legacy APIs. We've also moved processing of inbox rules out of the store and into the transport stack. We've moved quite a bit of calendar logic out of the store to the Microsoft Exchange Mailbox Assistants. And, we removed support for ExCDO, epoxy and item level security descriptors. Another area that hugely benefits from moving RPC endpoints to the middle tier is scalability for mailbox connections. In Exchange 2007, we were effectively limited to 60K connections per mailbox server due to limitations in the TCP/IP stack in Windows, where there was a fixed number of source ports regardless of the number of IP addresses. In Windows 2008, those limitations were removed, and Windows now supported one source port per IP address. However, we couldn't actually take advantage of that change because DSProxy was not updated to use the new feature. This means the Mailbox server is limited to 60k outbound TCP connections to the Global Catalog servers. The store process is hard-coded to only support 65,535 RPC context handles. All told, this limited us to 15,000 active mailboxes before even considering the message profile of these mailboxes and their effect on CPU scalability. The landscape changed significantly in Exchange 2010 with the introduction of the RPC client access service. Between Outlook clients and the CAS servers, we still have a one-to-one mapping of connections to clien t sessions. In addition we are able to disconnect idle client sessions, and free up the connection CAS used to talk to the Mailbox role for the idle clients. Now we are able to share a pool of 100 connections among all clients, and when we disconnect those clients they just hang around in a disconnected state until they need to perform some action again or until the client drops the connection. A representation of improved backend scalability in Exchange 2010 is shown below: For more information, review: Outlook Anywhere Scalability with Outlook 2007, Outlook 2003, and Exchange 2007 We were also able to introduce logic to the Address Book service that helped enable archive mailboxes, we made improvements in compliance features (for example copy on write for dumpster), and we provided unified GAL capabilities and a writeable GAL. Many thanks to Scott Schnoll, Victor Wang, Robin Thomas, Ross Smith IV and Vandy Rodrigues for their review and contributions! - Nagesh MahadevPublish S/MIME certificates for external contacts to Active Directory for use with Exchange Server 2007
In the past, if you wished to use S/MIME for e-mail encryption with an external recipient, you would add the recipient to your Contacts folder. This was typically done by having the recipient send you a digitally signed item and then right click on the recipient in the From field and click "Save to Contacts". This solution was difficult for Helpdesk and Administration personnel to manage, as only the mailbox user (or someone logged on as the user) could modify the Contacts. Rather than a warning that the certificate in the contact had expired, the user would see somewhat cryptic error messages when attempting to send a signed/encrypted message. Having seen a growing interest from customers regarding how to decrease administrative overhead associated with handling these issues (Helpdesk tickets, etc.), customers have requested information regarding how to save a remote recipient's public key to an AD Contact, so that it can be updated once, and addressed in Outlook via the Global Address List (GAL). A quick look at an AD contact vs. an AD user in Active Directory Users and Computers (ADUC) shows a vastly different experience with respect to certificates - there is essentially nothing exposed in the UI for the contact (on the left), while the user object has a rich certificate interface (on the right): Fortunately, using a tool like LDP, we find that both types of objects contain the needed attributes to allow us to store certificates for use with Outlook and/or OWA. The attribute that needs to contain the certificate is the userCertificate attribute, which exists for the object, but has no facility in the UI to load the certificate. Sounds like a job for Certutil.exe... This utility is part of Certificate Services in Windows Server 2003. It can also be downloaded here. http://www.microsoft.com/downloads/details.aspx?FamilyID=C16AE515-C8F4-47EF-A1E4-A8DCBACFF8E3&displaylang=en Certutil.exe is a command line tool that provides a way to manage certificates, particularly to add certificates to AD objects - like our contact. The syntax required is: This assumes some prerequisites: The certificate needs to have an "E" value in its subject. The "E" value must match the SMTP address assigned to the contact. The certificate needs to be valid - (validity period, trusted, etc.), or issues will crop up later. The user sending the signed/encrypted email has their own valid certificate. Executing the certutil syntax properly results in <ldp: Binary Blob> showing up in the userCertificate attribute if viewed from LDP. So far so good... Now all that remains is to open Outlook, create a new message, pick the newly "certified" contact from the GAL, set the message security options to encrypt, and the send the message. Again, provided that the user sending the message has their own certificate, this works like a champ, otherwise, they will see an error message indicating the sender doesn't have a valid certificate, and the message will have to be sent un-encrypted - more on this a little later. Things are essentially the same if using an internal (ie. not trusted in popular browsers) CA. For our testing purposes, we used Windows 2003 Certificate Services, and issued certificates using the default "User" template. (Discussion of templates, their care and feeding, etc. are beyond the scope of this article, please refer to http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx as a good starting point) The most common issue we encounter when using an "Internal" CA is that the CA is not trusted by either the client machine, the Exchange servers, or both. Opening a certificate on a machine that doesn't trust the CA will look as follows: This condition is manifested in OWA and Outlook as well, but with a different message (please click to see a bigger version): Once you have the certificate trust issue resolved, you'll see the following instead: Steps to publish the S/MIME certificate to Active Directory: 1. Obtain the public certificate from the user and save it where certutil.exe is loaded. 2. Open the certificate and verify the subject name that it is issued to. 3. Create a new mail enabled contact in the Exchange Management Console. 4. Give it a matching E mail address as the subject name on the certificate. 5. Open a command prompt. 6. Run certutil -dspublish c:\path-to-user.cer The utility will match the E= value to an item in Active Directory. If this is not found it will then try to match the distinguished name in the subject field to the distinguished name in Active Directory. If it does not find a match the operation will fail. You can verify the command was successful with ADSIEdit (as well as LDP.exe). The certificate will be placed in the userCertificate attribute on the matching contact object. It will be populated as an Octet string, so it will not be in a readable format. This attribute is <not set> by default. To remove the certificate simply remove the value from this field. In OWA, if you bring up the properties of the contact from the global address list, you will see the recipient has a valid digital ID for S/MIME - "Secure Messaging The Recipient has a valid Digital ID for encrypting e-mail messages." Troubleshooting So, you went through all the steps, and it still didn't work - got an error like the following: Most often, this indicates that the recipients certificate was issued by a Root CA, and/or an Intermediate CA, that isn't trusted - obtain the Root certificate, and any intermediates, from the remote Organization, and install them on the appropriate computers: From a workstation, you can just install the certificate using the Wizard. If you need to install it on a server, the best way to proceed is to Use the Certificates MMC to install the certificate, because you need to install it to the "Local Computer" account to trust CA. Go to Start > Run, type in MMC, and press Enter. Once the MMC opens, File > Add/Remove Snapin, Add the "Certificates" snapin... NOTE: choose the "Computer Account" radio button. Finish the wizard and you should see "Certificates (Local Computer)": Drill down to Trusted Root Authorities > Certificates folder, right click and choose Import: Work through the wizard, specifying the file to import: Once the wizard is complete, you should see the CA in the list. To be sure you are covered, it is best to repeat this for all Exchange servers in the Org for each CA Root certificate and/or Intermediate. Now when you look at the cert, it should look like: "But I can't get the certificate published using the tool!" - Make certain that the SMTP address configured in the certificate matches the AD contact. You should be able to publish even if the certificate is not trusted, although this isn't a good idea, as you will almost certainly run into the preceding error. Also note that if you try to publish a certificate into an AD contact that already has one, you will receive an error message indicating you can't overwrite the existing cert. Use ADSIEdit, or your favorite LDAP tool to remove the certificate and re-publish. Note: Be very careful when using tools like ADSIEdit, as they can cause significant damage if used incorrectly. A word about Certificate handling in OWA versus Outlook - In order for this to work the user sending email has to have a valid certificate installed on the machine from which they are sending. This is because the Exchange security model requires a certificate for both parties when sending signed/encrypted email (http://technet.microsoft.com/en-us/library/aa997737.aspx). OWA will detect the presence of the user's certificate, and perform the appropriate operation assuming: The certificates are issued for the intended purpose There aren't multiple certificates for the user in the certificate database The first one in the list is expired or otherwise invalid. OWA uses the first cert in the list, even if it is no good. Hopefully, the user has only one private key for decrypting messages, so this doesn't become a problem. If the user has several private keys, each one will need to be installed on the workstation where they are accessing their mailbox for the body of messages they need to decrypt. OWA will also handle the scenario where one certificate is issued for Encryption, and another is issued for Digital Signing. It determines which to use based on the values in the "Key Usage" attribute on the certificate: Outlook, on the other hand implements handling of multiple S/MIME certificates Settings, where the user can choose a certificate to be the default for signing/encrypting. The user can create a message to be sent to a user, and choose the certificate they wish for Outlook to refer to for Exchange Security purposes. This can be changed at any time by the user, and should work provided that they don't select an invalid cert. (http://office.microsoft.com/en-us/outlook/HP012305371033.aspx - Get a Digital ID: provides info on configuring certificates in the Trust Center) Note: The examples in this article were conducted using Exchange/OWA/Outlook 2007, using Windows 2003 AD and CA. You should see similar behavior from Exchange/OWA/Outlook 2003, but your experience may vary, particularly with diagnostic messages. We strongly recommend that you test this process extensively in your labs to make sure that it gives you the functionality that you expect. Additional reading http://msexchangeteam.com/archive/2007/08/20/446760.aspx - Secure Messaging with S/MIME and OWA on Exchange Server 2007 SP1 http://msexchangeteam.com/archive/2005/01/14/353167.aspx - Common Trust, Encryption and Digital ID Troubleshooting - for Microsoft Outlook and Microsoft Exchange users http://office.microsoft.com/en-us/outlook/CH100622191033.aspx - Security and privacy for Outlook 2007 How to - DJ Ball, Roman MaddoxConsidering 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'NeillFun with changing E-Mail Addresses
One may think that making changes to the e-mail address of a mailbox is a simple thing, but Exchange does a bit of work to ensure the changes are correct and will not cause problems in the system. Here's an overview of how the UI updates e-mail addresses and how it validates and checks for uniqueness when changes are made. E-Mail Address Attributes Exchange stores and uses information about the e-mail addresses of a recipient in the following attributes: proxyAddresses This is the main attribute where e-mail address information is kept. When you open the properties of a recipient in Outlook and look at the "E-mail Addresses" tab, you are looking at this attribute. This is a multi-valued string containing all the addresses that represent the recipient. Each value must have the following format: type:address For example: SMTP:nospam@online.microsoft.com When the type is in uppercase letters, the address is considered to be the primary address of that type and it is used as the default reply address of that recipient. When the type is in lowercase letters, the address is considered a secondary address and is used to resolve addresses during e-mail delivery, allowing the same recipient to receive e-mails directed to different e-mail addresses. For example: Primary: SMTP:currentAlias@domain.com Secondary: smtp:oldAlias@domain.com On the 'Users and Computers' snap-in, this property is edited on the 'E-mail Addresses' page of a recipient. targetAddress In contacts and mail-enabled users this attribute contains the type and address of the mailbox represented by the recipient. This will point to a mailbox outside the Exchange organization, for example, to a hotmail account or to another's company address. On the 'Users and Computers' snap-in, this property is edited on the 'Exchange General' page of contacts and mail-enabled users. mail The value of this attribute corresponds to the primary SMTP proxy address. Windows often displays this attribute as the e-mail address of the user. On the 'Users and Computers' snap-in, this property is edited on the 'General' page of recipients. textEncodedOrAddress The value of this attribute corresponds to the primary X400 proxy address. On the 'Users and Computers' snap-in, this property is edited by changing the primary X400 address on the 'E-mail Addresses' page of recipients. It is important to note that the values found in mail, textEncodedOrAddress and targetAddress must also be included in proxyAddresses with their respective types, otherwise they would not be picked up when Exchange makes searches against proxyAddresses. However, this creates a problem: we actually need to keep these attributes synchronized to each other when the administrator makes changes to them, either in the UI or with CDOEXM. The problem is aggravated because in 'Users and Computers' Windows implements the property page that sets the mail attribute, while the Exchange extension implements the property pages with targetAddress and proxyAddresses. Not only do we need to synchronize changes when the property page is saved but we need to synchronize when the administrator flips from one page to the other, to keep the UI consistent. To do that, we run what we call the proxy-sync mechanism. Proxy-Sync Scenarios Proxy-Sync runs when an administrator makes a change in one of the e-mail attributes of a recipient and that change needs to be synchronized to another attribute. For example, when mail changes, the primary SMTP entry in proxyAddresses must also be updated so that both addresses are synchronized, but if you try to delete the mail attribute without mail-disabling the recipient, then we copy the primary SMTP address back to mail. The following list summarizes the changes supported by proxy-sync since Exchange 2000 SP2: 1. Action: Remove e-mail from General page. Results: Primary SMTP from proxyAddresses is copied back to mail. 2. Action: Modify e-mail on General page. Results: There are four cases to be considered: o If the new address already exists in proxyAddresses and: · it is the primary SMTP address: proxy is in sync already. · it is a secondary SMTP address: demote the curr ent primary SMTP and promote the new address to primary SMTP. o If the new address does not already exists in proxyAddresses and: · targetAddress is the primary SMTP: demote the current primary SMTP and add the new address as primary SMTP. · targetAddress is a secondary SMTP: replace the primary SMTP with the new address. 3. Action: Modify the primary SMTP on E-mail Addresses page, either by editing or by promoting a secondary address to primary. Results: new primary SMTP is copied to mail. 4. Action: Modify the primary X400 on E-mail Addresses page, either by editing or by promoting a secondary address to primary. Results: new primary X400 is copied to textEncodedOrAddress. 5. Action: Modify the address corresponding to targetAddress in the E-mail Addresses page. Results: The new address is copied to targetAddress. Actions 3 and 4 also apply if the edited address is a primary proxy. 6. Action: Modify the targetAddress in the Exchange General page of contacts and mail-enabled users. Results: The following rules are applied: o If the old targetAddress is the primary SMTP and the new targetAddress: · is also SMTP: remove the old primary SMTP. · is not SMTP: keep the primary SMTP intact. · In either case, continue following the next rules: o If there is already a primary address for the same type, add the targetAddress as a secondary address. o If there is not a primary address for the same type, add the targetAddress as a primary address and if it is SMTP or X400, copy to mail or textEncodedOrAddress, respectively. E-mail Address Validation Well, now that all our e-mail addresses are synchronized, we can try to save them, right? No, we are not quite there yet. Before saving we must make sure that all addresses are valid, according to their type. When validating the proxyAddresses attribute, we'll check the following: o There must be a primary SMTP address o There can be only one primary address of each type o Every secondary address type must have a corresponding primary address o All addresses must pass validation of their type · This is actually done by the proxy generation DLL associated with each type. I won't go in details on that here since you can find more information about them in MSDN. · Now, these DLLs will not be installed in an admin-only installation, so we need to RPC to an Exchange server and let the server perform that validation. The Exchange System Attendant service responds by calling each proxy DLL and letting them validate the e-mail addresses typed by the user. Can we save now? Close, but not yet. There is still one step left. Uniqueness Check We would not like to let an administrator accidentally create duplicate e-mail address when we can prevent that from happening. I mean, if that happens messages would start returning, people will complain and everybody gets frustrated. So let's do this one last thing before saving changes to the e-mail addresses of a recipient: let's make sure they are all unique in the organization. To do that, we perform an LDAP query against the Global Catalog, looking for any object that has any of the proposed values in its proxyAddresses attribute. The query will look somewhat like this, with as many clauses as e-mail addresses we need to check: (| (proxyAddresses=SMTP:alias@domain.com) (proxyAddresses=smtp:alias2@domain.com) ) Of course, we need to properly format and escape the e-mail addresses in the query but most importantly, we need to be aware of the fact that there may be one object with the same addresses that we're trying to save, which would be the object we are editing. That one is ok, but if anyone else shows up in that query, we have a duplicate and we do not allow the changes to be persisted. What about Recipient Policies? You may be wondering why I haven't mentioned Recipient Policies anywhere. The process described above happens in the user interface, completely independent of Recipient Policies. It goes without saying that once the recipient is updated, Recipient Policies will go make sure everything is according to policy, but that's another story. - Fabio Pintos
