Why can't I modify the objects on my ADC Tools created Recipient CA?
If you create a Recipient Connection Agreement (RCA) with the ADC tools wizard and then go in to view the settings of that RCA, you may notice that the “Select the objects that you want to replicate” options on the From Windows tab are grayed out and you cannot make changes… Example: The reason for this is because of the custom filter created for the RCA by the ADC tools. If you look at the values for the attribute msExchServer1SearchFilter on the agreement itself, you will see a filter specified that is similar to: (&(|(objectclass=user)(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=ORG1/ou=SITE1/cn=*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE))); This is a custom search filter that (in this case) searches for objects in Active Directory that are either of class user, contact, or group AND that also belong to the Administrative Group called SITE1 (or that have been deleted and need that deletion to replicate across to the 5.5 Directory) Since this is a “custom” filter, the objects can’t be edited via the normal GUI interface and that is why the check boxes are not modifiable. Once again you can see from the filter that the connection agreement is in fact already set to replicate users, contacts or groups despite what the GUI seems to indicate at first glance. If you have multiple Administrative groups that have users in the same Active Directory location you would have multiple auto-created RCAs as these will ONLY replicate objects that match the Administrative Group listed in the filter. For example, a second Administrative Group (called AG2) with objects in the same Active Directory location would have a filter like the following: (&(|(objectclass=user)(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=ORG1/ou=AG2/cn=*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE))); Ultimately, if you want or need more flexibility with connection agreements (such as limiting or modifying the objects controlled by the RCA) you should create the connection agreements manually using the ADC Services Snap-in instead of having the ADC tools create them automatically. - Kyle LewallenAre ghosts modifying distribution groups in your mixed-mode environment?
We've seen a few issues recently where members of DGs (Distribution Groups) in mixed-mode Exchange 200x and 5.5 seem to randomly and mysteriously disappear. We thought we'd share one known root-cause and also show you how to prevent the problem while doing your migration, if for whatever reason you are still running Exchange 5.5 =). One easy way to prevent this problem (and a few others) is to ALWAYS use the Exchange 2003 post SP1 cross-site mailbox migration wizard if you ever have to move mailboxes in a mixed-mode environment. With that said, typically the problem occurs when you use a directory export/import to move mailboxes between Exchange 5.5 sites. For example, if you have two Exchange 5.5 sites Site S (Source) and Site D (Destination) and you would like to move all the mailboxes in Site S to Site D you might perform the following steps. (When we refer to a DL we mean a Distribution List on the Exchange 5.5 side and when we refer to DG we mean a Distribution Group on the Active Directory side) Extract all the DLs of the mailboxes you intend to migrate Export the directory Information from the source Exchange 5.5 server in Site S Delete the source mailboxes in Site S Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also wait for the Active Directory Account to become mailbox-disabled. Do a directory import of the mailbox information in Site D to recreate the mailboxes. Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site The problem occurs after step 4. The following key points should help you understand why. Replication between Exchange 5.5 sites is governed by USN-Changed values. Any changes made to an object in a directory in one site only replicate to other sites if that object's USN-Changed value is higher than the corresponding value in some other site. For the special case of a mailbox deletion, you would expect the USN-Changed value for any DL that the mailbox is a member of to increment after the mailbox deletion. This is, however, not necessary because when you delete a mailbox from its 'home' site, the member property of the DL changes and the read-only copy of the mailbox in all the other sites gets deleted. When the read-only copy is deleted in all the other sites the DL membership is updated as well. The salient point is without incrementing a DL's USN-Changed, all the necessary changes for the sites to be in-sync are properly accounted for. This works well for a pure Exchange 5.5 environment but creates a problem for a mixed-mode one with an ADC (Active Directory Connector) in the mix. As we know, the ADC compares the msExchServer2HighestUSN value on the RCA (Recipient Connection Agreement) to the USN-Changed value of an object in the Exchange 5.5 directory to determine whether the Exchange 5.5 object should be replicated to the AD. If the USN-Changed on an object is greater than the msExchServer2HighestUSN on the RCA, the object has been changed in the Exchange 5.5 directory and needs to be updated in the AD. If msExchServer2HighestUSN is greater than or equal to USN-Changed, no changes have occurred on the 5.5 object that need to be updated (replicated to) on the AD side. See the following knowledge base article for further details 253840. In this situation, since the DLs' USN-Changed isn't incremented in the 5.5 directory when you delete the mailboxes, the corresponding DG (Distribution Group) membership in the AD isn't updated. If you later make changes that increment the USN-Changed on the DL, the entire object (including the earlier deletions) is replicated to the AD side and so some members seem to randomly disappear from the DG's members list. While replication in Exchange 5.5 is object-based and replication in the AD is attribute-based, Exchange 5.5 to AD replication is still object-based (think lowest common denominator). The solution to this problem is to force the USN-Changed on the DL to increment after performing the deletions in step 3. A DL's USN-changed increments under the following scenarios: If you use the Exchange 5.5 Administrator program to open the DL's properties, modify any value and click Apply or OK (Or if you modify the DL's properties by doing an directory export/import with the standard header fields) If you use the Exchange 5.5 Administrator program to open a mailbox's properties and remove a DL from the list of DLs that the mailbox is a member of If the DL is updated by DRC or ADC replication changes from other 5.5 sites or from the AD respectively Again, a DL's USN-Changed does not increment when you use the Exchange 5.5 administrator program to delete a mailbox from the DLs membership. To force the USN-Changed value on the DL to increment you need to make a 'dummy' change that falls under a, b or c after step 3. Our new steps to ensure we avoid the problem would therefore be: Extract all the DLs of the mailboxes you intend to migrate Export the directory Information from the source 5.5 server in Site S Delete the source mailboxes in Site S Use the Exchange 5.5 Administrator program to modify the "notes" field on all the DLs that contained the deleted mailboxes to force an increment of USN-Changed value. This step is critical Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also trigger RCA replication and make sure that the 'member of' list for the AD user accounts that correspond to the deleted mailboxes is empty (except built-in groups such as Domain Users etc) Do a directory import of the mailbox information in Site D to recreate the mailboxes Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site. Add the migrated mailboxes to the corresponding DLs manually using the Exchange 5.5 Administrator program. This step may not seem necessary but it is. Usually an administrator may notice that the member list is still present on the AD after performing the previous steps and therefore assume that nothing more needs to be done on the Exchange 5.5 side. Later when some other change increments the USN-Changed the deletions replicate to the AD and members seem to randomly disappear from DGs. Everything should work fine and dandy at this point and you needn't worry about 'ghosts' modifying your DGs! - Jasper Kuria and William YangDoes your Transport think it is Squeaky Lobster Day in your CountryOrRegion?
Today is the magical day when parents tell their tucked-in children the story of the Squeaky Lobster. So here's a Squeaky Lobster-ish post to celebrate the day. In Exchange 2007, we introduced transport rules – a powerful feature that allows you to inspect different parts of a message such as sender, recipient, subject and headers and take actions like rejecting a message, deleting it, redirecting it to another recipient, adding a message header or a disclaimer. In previous versions of Exchange, you would need to write a transport event sink to accomplish similar things. With an easy-to-use interface in the EMC , transport rules make such tasks as easy as creating Inbox rules (created by users using Outlook/ OWA ). Command-line jockeys can create and manage transport rules using *-TransportRule cmdlets from the Shell. More about transport rules in Understanding Transport Rules. In Exchange 2010, we added a number of new predicates (which are used to create conditions and exceptions), including the ability to inspect attachment content and predicates to evaluate Active Directory attributes of the sender or recipients. A complete list of predicates can be found in Transport Rule Predicates. Ability to inspect Active Directory attributes of the sender or recipients dramatically increases the number of things you can check and the type of rules you can create. For example, you can check if the sender or recipients are in the same department, report to the same manager, check if the sender is the recipients’ manager (or the other way round), check the sender's title, city, state or country, amongst other things. The list of supported attributes is included in the Predicate Properties table in Transport Rule Predicates, or you can also see them in the New Transport Rule and Edit Transport Rule wizards in the EMC . Evaluate the sender's country or region You can use the predicate to evaluate the sender's country. This can be useful in many scenarios - for example, applying a disclaimer to messages based on the sender's country. Important: When using Active Directory attributes to meet business requirements, you must have appropriate processes in place to ensure the necessary attributes are populated and up-to-date. You can add the country/region property to a user or contact using ADUC , the EMC , the Shell or by using LDAP utilities. If you use ADUC or EMC, you’re greeted with a nice little drop-down list to pick a country/region from. If you use the Shell, you must use the corresponding cmdlet to populate the CountryOrRegion property – Set-User for user accounts, Set-Contact for contacts. Fig 1: You can select a recipient’s country or region from recipient’s properties in EMC You need to create a rule to check if message sender is from a specified country – let’s continue with Germany as the example, to apply a disclaimer. You can use the when the sender’s properties contain specific words predicate from the New Transport Rule wizard in EMC to check the CountryOrRegion property. The predicate allows you to pick a supported property and you can type in a string to match. For example, if you’re trying to match senders from Germany, you instinctively type in Germany. Fig 2: Checking a sender CountryOrRegion property using a transport rule But the transport rule doesn’t fire on any messages sent by recipients from Germany! You check the rule in EMC – it says Germany. It’s spelt correctly, no typos. You use the Shell to retrieve the properties: (Get-TransportRule MyRule).Conditions | fl * The value correctly displays as Germany: Words : {countryorregion:Germany} Name : SenderAttributeContains Rank : 36 LinkedDisplayText : when the sender's properties contain specific words IsValid : True You check the recipient’s country property using the Shell. Get-User bsuneja | select cou* Squeaky Lobster! The value is Germany! Why wouldn't the rule fire? The CountryOrRegion Property Although the CountryOrRegion property displays the country’s name (think of it as a display name), what’s stored in the Country-Name attribute (ldapDisplayName: c) in the recipient object in Active Directory is the 2-letter ISO 3166-1 country/region identifier for the country. For Germany, it’s DE. The full list of ISO codes can be found in the ISO 3166-1 decoding table . (Update: A better-formatted list can be found in ISO 3166-1 on Wikipedia). Note: Active Directory objects also have two more attributes to identify country or region: 1) Country-Code (ldapDispla yName: countryCode), which corresponds to the ISO 3166-1 numeric code 2) Text-Country (ldapDisplayName: co), which is the country name. However, only the Country-Name attribute is replicated to the Global Catalog. Update the rule Armed with this information, you can fix the rule in EMC. Figure 3: Use the Edit Transport Rule wizard to update values for the CountryOrRegion property Or use this command from the Shell to update the SenderADAttributeContains predicate. Set-TransportRule MyRule –SenderADAttributeContains “CountryOrRegion:DE” Happy Squeaky Lobster Day! Bharat SunejaFun 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 PintosADModify.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 Winter
