DMARC Quarantine Issues

Posted on Leave a commentPosted in dkim, dmarc, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, spf, spoof

I saw the following error with a client the other day when sending emails from the client to any of the Virgin Media owned consumer ISP email addresses (,, etc.) gave this error:
vLkg1v00o2hp5bc01Lkg9w DMARC validation failed with result 3.00:quarantine

In the above, the server name (… might change as will the value before the error, but either DMARC validation failed with result 3.00:quarantine or 4.00:reject is the end of the error message.

We resolved this error by shorting the DMARC record of the sending organization. Before we made the change we had a DMARC record of 204 characters. We cannot find a reference online to the maximum length of a DMARC record, though we could successfully add a record of this length to Route 53 DNS provided by AWS, though a record of 277 characters was not allowed in AWS. Other references online to domain character length seem to imply that 255 characters is the max, but not specifically for DMARC.

So, shortening the DMARC record to remove two of the three email addresses in each of the RUA and RUF values was the fix that we needed. This change was done for two reasons, first the above error occurred only with emails to Virgin Media and sometimes an NDR would be received and other times the NDR would fail, but the original email never made it through and secondly the two removed email addresses where not actively being checked for DMARC status messages anyway and so there is no harm in the removal of them from the DMARC record anyway!

The original DMARC record we had this issue with looked like this (xxx.xxxxx representing the client domain):

v=DMARC1; p=quarantine; fo=1;rua=mailto:admin@xxx.xxxxx,,mailto:dmarc@xxx.xxxxx;ruf=mailto:admin@xxx.xxxxx,,mailto:dmarc@xxx.xxxxx;

Then we changed the record to the following to resolve it:

v=DMARC1; p=quarantine; fo=1;;;

Reducing the length of the record resulted in DMARC analytics and forensic email not going to mailboxes at the client (one of whom those mailboxes did not exist anyway) and only going to the UK government DMARC policy checking service, but most importantly for a client that has a requirement to respond to citizen’s emails (and whom could easily be using Virgin Media email addresses) we resolved the issue.

On-Premises Public Folders, Exchange Online, And Multiple Forests

Posted on 1 CommentPosted in exchange online, Exchange Server, Office 365, Public Folders

Here is a scenario I have come across in a few clients in just the last few weeks. This is not something that I recommend implementing lightly, as there are implications. But it does allow some very specific problems with public folder integration to be solved in the short term.

The specifics of the scenario is that with Exchange Online mailboxes and on-premises public folders, each user in Exchange Online needs a login account in the on-premises forest. That is easy for hybrid mode Exchange Server to Exchange Online, but once you move to multi-forest hybrid it is not. In multi-forest hybrid you will have users from more than one forest (of course).

When you set up integration between Exchange Online and an on-premises Exchange organization, you choose the single organization that you can proxy public folder requests to. This is done with Set-OrganizationConfiguration in Exchange Online and the value is the email address(es) of mailboxes that are located on the same servers as the public folder servers on premises – these are known as the public folder proxy mailboxes. For example this would look like Set-OrganizationConfiguration -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes pfProxy1. Once this is done, all Exchange Online users get allocated one of these email addresses as their public folder proxy address. When the user uses Outlook, the AutoDiscover response for their mailbox will include a publicFolder value that contains this email address given to the users mailbox. For example, it would look like this:




Outlook will then do AutoDiscover for that mailbox (in the same way that it does AutoDiscover for shared mailboxes) and attempt to login to the public folders (Outlook 2010) or show “Public Folders” in the Outlook tree folder view and wait until the user expands to attempt to connect (Outlook 2013 and later). If the user has an account on-premises then the Public Folder hierarchy is shown and the user can open folders for which he or she has permission.

But, if the user belongs to another forest, they do not have an account in the forest that the public folders are in and so login to the public folder hierarchy fails.


So how do we solve this. There is one way I have tested, and another way I have yet to test. The first way turns off the public folders for the users in all the non-primary forest for public folders. They cannot access public folders at all, unless you implement a third party folder migration software and even these might not work. The steps to implement this “fix” is to begin to implement public folder migration, but actually to stop very early in the process and jump to near the end of that process. So first create a new public folder in Exchange Online. As you are using public folder proxies, you can only create public folders that are held for migration, and that is the key to this idea. So New-Mailbox pfMailbox1 -PublicFolder -HoldForMigration will create a new empty (and that is important) public folder mailbox in Exchange Online. Now near the end of published process for public folder migration there is a step where you can individually set cloud mailboxes to use the cloud public folders. You do this with Set-Mailbox name -DefaultPublicFolderMailbox pfMailbox1 and this user will now only look at the empty cloud public folders and not attempt to connect on-premises. Therefore if you do this for all mailboxes from the non-primary forest for public folders then they will stop failing to login on-premises. Sure, they loose public folder access to their original folders as well, but that was the risk that that you would have been discussing with your consultant before you started migrating.

My second, untested option, is to instead run the Set-OrganizationConfiguration option but to use proxy mailboxes from multiple forests that have previously created and synced. And rather than allowing Exchange Online to randomly distribute the proxy mailboxes across all the users, you would provision the user with the correct proxy mailbox for the organization they are in. Assume therefore that Forest1 has pfForest1Proxy and Forest2 has pfForest2Proxy1. You would run Set-OrganizationConfiguration -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes pfForest1Proxy,pfForest2Proxy and then individually ensure that Set-Mailbox <each user in Forest1> -DefaultPublicFolderMailbox pfForest1Proxy and that Set-Mailbox <each user in Forest2> -DefaultPublicFolderMailbox pfForest2Proxy. Note that this is not tested. Please let me know if this works for you in the comments if I don’t get to test it first!

Forcing Transport Level Secure Email With Exchange Online

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Exchange Server, Office 365, security, starttls, TLS

In Exchange Online there are a few different options for forcing email to require an encrypted connection. These depend upon the level of licence you have, and some of them are user based (Office 365 Message Encryption for example), but there are two ways to force TLS (transport layer security) for the email between when the message leaves Office 365 and arrives with the recipient email system.

The first of these is a Mail Flow rule, and the second of these is a Conditional Connector. Only the second of these works!

The first, just for clarity, appears to work but it is not 100% reliable and will end up with stuck emails unless you configure the rule 100% correct. The second option is the recommended option ongoing.

For completion, we will also look at forcing TLS inbound to Exchange Online

Force TLS with Mail Flow Rules

This option relies on a Transport Rule (or mail flow rule) setting called “Require TLS”. This below example shows a UK Government requirement that states that emails to certain government departments (by domain name) should enforce the use of TLS:


This rule uses the condition “if the recipient address includes” and the list of UK Government domains that should be secured. This list is found at and for test purposes I have added my own domains to the list. The action for this rule is “to require TLS encryption”.

As mentioned above, this rule is not 100% reliable, and the the issue is when you have a Hybrid Exchange Online environment back to on-premises Exchange, though that connector back to on-premises uses TLS, the rule to force TLS conflicts and the email stays in Exchange Online in a pending state and is never delivered.
To avoid this issue, an exception is required to the rule to exempt it for your on-premises domains.

Force TLS with Conditional Connectors

This is the recommended route for forcing TLS. It requires two settings created. The first is a Conditional Connector as shown:


You must select “Only when I have a transport rule set up that redirects messages to this connector” on the connector use page.


MX delivery is the most likely option, and then either any digital certificate or issued by a trusted third party depending upon your requirements.


If you have more than one domain to force TLS to, then do not enter the end certificate info here, as it will be different for each domain.

Now that you have the connector in place, which will only be used is rules route the emails to that connector, you can create the rule.


We have purposely excluded the domains we had an issue with when using “Require TLS”, but Microsoft say that workaround should not be needed – I will update this post once I know that for sure! Also, as the rule shown in the screenshots adds a disclaimer so that we can check that the rule is being executed.

Inbound Required TLS with Connectors

To force inbound TLS requirements, so that email from given domains are rejected if they do not open a TLS session with your organization to send an email you create a Partner to Office 365 connector. This connector will force TLS or reject the email inbound if that cannot happen:




And then choosing “Reject email messages if they aren’t sent over TLS” as part of the connector conditions:



XOORG, Edge and Exchange 2010 Hybrid

Posted on Leave a commentPosted in 2010, Edge, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, Office 365

So you have found yourself in the position of moving to Exchange Online from a legacy version of Exchange Server, namely Exchange 2010. You are planning to move everyone, or mostly everyone to Exchange Online and directory synchronization plays a major part (can it play a minor part?) in your plans. So you have made the option to go hybrid mode when you discover that there are manual steps to making Exchange 2010 mail flow to Exchange Online work if you have Exchange Edge Servers in use.

So, what do you do. You look online and find a number of references to setting up XOORG, but nothing about what that is and nothing about what you really need to do. And this you found this article!

So, how do you configure Exchange Server 2010 with Edge Servers, so that you can have hybrid mode to Exchange Online.

Why You Need These Steps

So you ran the hybrid wizard, and it completed (eventually if you have a large number of users) and you start your testing only to find that emails never arrive in Office 365 whilst your MX record is still pointing on-premises. After a while you start to get NDR’s for your test emails saying “#554 5.4.6 Hop count exceeded – possible mail loop” and when you look at the diagnostic information for administrators at the bottom of the NDR you see that your email goes between the hub transport servers and the edge servers and back to the hub transport servers etc. and about three or so hours after sending it, with the various timeouts involved, the email NDR arrives and the message is not sent.

The problem is that the Edge Server sees the recipient as internal, and not in the cloud, as the email has been forwarded to the, and Exchange 2010 is authoritative for this namespace. You are missing a configuration that tells the Edge that some emails with certain properties are not internal, but really external and others (those coming back from the cloud) are the only ones to send internal to the on-premises servers.

So what do you do?


Before you run the hybrid wizard you need to do the following. If you have already run the wizard that is fine, you will do these steps and run it again.

  1. Install a digital certificate on all your Edge Servers that is issued by a trusted third party (i.e. GoDaddy, Digicert and others). The private key for this certificate needs to be on each server as well, but you do not need to allow the key to be exported again.
  2. Enable the certificate for SMTP, but ensure you do not set it as the default certificate. You do this by using Exchange Management Shell to Get-ExchangeCertificate to key the key’s thumbprint value and then running Enable-ExchangeCertificate –Thumbrint <thumbprintvalue> –Services SMTP. At this point you are prompted if you want to set this certificate as the default certificate. The answer is always No!
  3. If you answer yes, then run the Enable-ExchangeCertificate cmdlet again, but this time for the certificate thumbprint that was the default and set the default back again. If you change the default you will break EdgeSync and internal mail flow for everyone. And you must use the self-signed certificate for EdgeSync and this third party issued certificate for cloud mail flow, as you cannot use the same certificate for both internal and external traffic.
  4. The certificate needs to be the same across all your Edge Servers.
  5. If you are doing multi-forest hybrid, then the certificate is only the same across all the Edge Servers in one Exchange Organization. The next organization in your multi-forest hybrid needs to use a different certificate for all its Edge Servers.
  6. Then take this same certificate and install it on a single Hub Transport server on-premises. The hybrid wizard cannot see what certificates you have on the Edge Servers, so you need to help the wizard along a bit. Again, this certificate needs enabling for SMTP, but not setting as the default certificate.

Running The Hybrid Wizard

Now you can run the hybrid wizard. The important answers you need to include here are that the hub transport server that you pick must be the one that you placed the certificate on, as you cannot pick the Edge Servers that you will use for mail flow in the wizard. But you will need to enter the IP addresses that your Edge Servers are published on the internet as, and you will need to enter the FQDN of the Edge Servers as well.

Complete the wizard and then time for some manual changes.

Manual Changes

The hybrid wizard will have made a send connector on-premises called “Outbound to Office 365”. You need to change this connector to use the Edge Servers as the source servers. Note that if you run the hybrid wizard again, you might need to reset this value back to the Edge Servers. So once all these required changes are made, remember that running the wizard again could constitute an unexpected change and so should be run with care or out of hours.

Use Set-SendConnector “Outbound to Office 365” -SourceTransportServers <EDGE1>,<EDGE2> and this will cause the send connector settings to replicate to the Edge Server.

Next get a copy of the FQDN value from the receive connector that the hybrid wizard created on the hub transport server. This receive connector will be called “Inbound from Office 365” and will be tied to the public IP ranged of Exchange Online Protection. As your Edge Servers receive the inbound emails from EOP, this receive connector will serve no purposes apart from the fact that its settings are the template for your receive connector on the Edge Servers that the wizard cannot modify. The same receive connector will also have a setting called TlsDomainCapabilities and the value of this setting will be AcceptOorgProtocol is the XOORG value that you see referenced on the internet, but it is really called AcceptOorgProtocol and this is the value that allows the Edge Server to distinguish between inbound and outbound mail for your Office 365 tenant.

So on each Edge Server run the following cmdlet in Exchange Management Shell to modify the default receive connector: Set-ReceiveConnector *def* -TlsDomainCapabilities -Fqdn <fqdnFromTheInboundReceiveConnectorOnTheHubTransportServer>.

This needs repeating on each Edge Server. The FQDN value ensures that the correct certificate is selected and the TlsDomainCapabilities setting ensures you do not loop email to Office 365 back on-premises again. Other emails using the Default Receive Connector are not affected by this change, apart from now being able to offer the public certificate as well to their inbound partners.

You can now continue with your testing knowing that mail flow is working, so now onto AutoDiscover, clients, free/busy, public folders etc. etc. etc.

Capax Zantas EAS EWS 501 Errors

Posted on Leave a commentPosted in EAS, Exchange Server, Kemp, Load Master, Zantas

Whilst load balancing Exchange 2013 with a Capax Zantas EAS deployment in place I was reminded of an issue I experienced a few years ago with a Kemp load balancer. The EAS app for OWA was failing with various errors such as:


Communication with service failed. The service might be down or misconfigured. Error code: 500

As well as the search functionality never returning results.

And in the EASOWABackend log file we were seeing the following:

w3wp.exe Error: 0 : 22 : [09/23/2016 10:13:22.880 AM] User EWS Call failed Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The remote server returned an error: (501) Not Implemented. —> System.Net.WebException: The remote server returned an error: (501) Not Implemented.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.GetResponse()
   at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
   — End of inner exception stack trace —
   at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
   at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
   at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
   at Microsoft.Exchange.WebServices.Data.ExchangeService.InternalConvertIds(IEnumerable`1 ids, IdFormat destinationFormat, ServiceErrorHandling errorHandling)
   at Microsoft.Exchange.WebServices.Data.ExchangeService.ConvertId(AlternateIdBase id, IdFormat destinationFormat)
   at EASOWA2013.EASOWABackend.OpenMessage(String owaID, String userEmail, String authToken, String pageURL)

This error contained a 501 Not Implemented message, and this message was getting exposed in OWA. But this error was not present in any of the Exchange Server logs, so it was not being caused by Exchange. This led us to looking at the load balancer, and testing EAS when bypassing the load balancer. To bypass the load balancer requires host file changes and changing the EAS configuration, so it is not a trivial change. When the load balancer was out of the traffic path everything worked fine.

Under the Kemp system logging (Logging Options > System Log Files > System Message File) we were seeing:

Sep 22 16:39:09 cwh-kemp01 kernel: L7: badrequest-client_read [192.168.x.y:44987->] (-501):] (-501):] (-501):] (-501):] (-501):] (-501):] (-501):] (-501):] (-501):] (-501):] (-501):

Where 192.168.x.y was the client IP and was the load balanced IP for Exchange.

With reference to the above linked article, the fix was to change the Kemp’s handling of the 100-Continue feature and by changing the setting to RFC-7231 Compliant EAS in OWA started working:


Photos, Exchange, And The File System

Posted on 1 CommentPosted in 2013, 2016, Exchange Server, Office 365, owa

On an Exchange 2013 and later server this is a folder called photos that gets created after installation and can contain a couple of user photos for some of your users. How does it get there and what does it contain?

The photos folder appears (on 2016 anyway) when the user uploads a photo (via OWA). Two images are created one 96square and the other 648square. They are made in a folder unique to the user and on the mailbox server that contains their active mailbox at the time of upload.

To reproduce this, login to OWA. Determine which server is currently the active server for that mailbox and then access the file system of that server. You are looking for “C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess” though it will be wherever Exchange Server was installed if not the C: drive. If anyone has uploaded photos already via this server then you will see a folder named photo. You can delete this folder without impact (unless someone is actively uploading a photo at that exact time).

In OWA, click the photo icon top right and then click Change:



Click Upload photo and select a photo. I’ve used the sample pictures that are installed on Windows 7 in this example:


At this point a copy of the photo is uploaded to a web service on Exchange Server. Click Save above your chosen photo. At this point the photo folder in the ClientAccess folder on the server that is active for your mailbox is created. Inside this folder you will see a subfolder called Inside this folder will be two subfolders called HR96x96 and HR648x648. Inside each of these will be the JPEG file that was created at the time of saving the upload. The size of each will match the folder name and the name of the file will be _Alias-UNIQUEID. If the user deletes their photo then a 0 byte JPEG file will be created in the folder.

Note that these two photos are not a cache of the photo for the Exchange Server to download to other users. They are just used during uploading the photos. Once uploaded they are resized using this file system location and then stored in their respective locations. The 96×96 photo (at less than 100Kb) is stored in the Active Directory and the 648×648 image is stored in the Exchange 2013 or later mailbox for use by Exchange, Skype for Business and SharePoint.

If there are policies and privacy laws that state the caching of images on the file system must be avoided, then you should be able to delete the photo upload cache at your convenience.

The photo folder does not appear on another server when viewing that user with a photo in their mailbox. Requesting the photo is done via owa/service.svc and not AFAIK from a file on the file system.

Deleting the folder after the fact did not impact my test users photo (as its now in the mailbox and not read from the file system). If this mailbox is later migrated to Office 365, then the photo will migrate with the mailbox as it is part of the mailbox. If the photo stored in AD is less than 100kb then it will be synced to Azure AD.

Exchange Online Archive–Counting Archives

Posted on Leave a commentPosted in archive, exchange, exchange online, Exchange Server, EXO, IAmMEC, Office 365

If you are using Exchange Online Archive and what to get a count of the number of users with an archive, or a list of the users with an archive, then the following PowerShell scripts will give you this info:

List all users with an Exchange Online Archive:

Get-MailUser -ResultSize Unlimited | where {$_.ArchiveName -ilike “In-Place Archive*”}

Count all users with an Exchange Online Archive:

(Get-MailUser -ResultSize Unlimited | where {$_.ArchiveName -ilike “In-Place Archive*”}).Count

Both of these PowerShell cmdlets need to be run in Exchange Online via Remote PowerShell.

Exchange Server and Missing Root Certificates

Posted on Leave a commentPosted in 2007, 2010, 2013, exchange, exchange online, Exchange Server, federation, Free/Busy

I came across an issue with a clients Exchange Server deployment today that is not well documented – or rather it is, but you need to know where to look. So I thought I would document the troubleshooting steps and the fix here.

We specifically came across this error when testing Free/Busy for an Office 365 migration, though it could happen for a variety of reasons. Free/Busy and other lookups in a cross-forest Exchange Server deployment require a working organization configuration and this was failing. Running Test-FederationTrust (a prerequisite of the organization relationship) in verbose mode (add -Verbose to the end) returned the following:

Unable to retrieve federation metadata from the security token
service. Reason: Microsoft.Exchange.Management.FederationProvisioning.FederationMetadataException: Unable to access the
Federation Metadata document from the federation partner. Detailed information: “The underlying connection was closed:
Could not establish trust relationship for the SSL/TLS secure channel.”.

The final result of the test will also show two errors for “Unable to retrieve federation metadata from the security token service.” and “Failed to request delegation token.”

The last part of the verbose error is the clue here. The server in question is unable to make an SSL/TLS connection to the endpoint that the federation trust needs to reach to get the federation trust metadata. That endpoint is listed right at the start of the Verbose output. It reads:

VERBOSE: [16:53:08.306 GMT] Test-FederationTrust : Requesting Federation Metadata from

Now that we have a URL and an error message, check that the URL is reachable from each of your Exchange Servers. At my client today we found one server could not successfully reach this endpoint without an SSL error turning up in the browser. The problem was that the certificate that the endpoint is secure with is issued by the Baltimore Cybertrust Root Certificate – one that Microsoft uses for lots of services, but the root certificate was not installed on that machine. Lots of root certs where missing from that machine as it had never had a root certificate update applied to it.

We installed the latest Root Certificate Update and then the federation trust worked and free/busy etc. (mail tips, cross-forest message tracking etc.) all worked fine.

Exchange 2013 Partner Applications and Error 2008

Posted on 2 CommentsPosted in Exchange Server, Lync Server, OAuth, Skype for Business Server

When Exchange Server 2013 is configured to connect to Lync / Skype for Business Server one of the steps is to create a partner application. When this is first run the partner application stores the certificate presented by Lync Server in the Active Directory configuration partition. If the certificate changes on the Lync Server then the Exchange Server will start to alert about this every 15 minutes with the following warning: MSExchange OAuth and Event ID 2008.


To fix this error we need to update the Active Directory configuration where the metadata info is kept (CN=LyncEnterprise-guid,CN=Partner Applications,CN=Auth Configuration,CN=Exchange Organization Name,CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=domain,DC=co,DC=uk)

To do this you need to start Exchange Management Shell on Exchange 2013 and remove the Lync partner application. Immediately after you have done this you can create the partner application again. The cmdlets for this are as follows:

is the same as you used when you first created the partner application. This is as follows:

  1. In the Exchange Management Shell confirm you have one Lync partner application with Get-PartnerApplication | FL
  2. In the Exchange Management Shell run Remove-PartnerApplication Lync* and then confirm that you want to do this.
  3. In the Exchange Management Shell, change directory to the Exchange scripts folder with cd $exscripts
  4. Then run the script to configure a new partner application. An example would be .\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl ‘’ -ApplicationType Lync where the URL points to the Lync server and contains a valid name for the certificate on the Lync Server.

This should return the following and report that the configuration has succeeded.


Your 2008 repeating errors in the Event Viewer will now be gone.

Qualifications in Exchange Signatures

Posted on Leave a commentPosted in 2013, active directory, exchange, Exchange Server, Global Catalog, IAmMEC, iQ.Suite

In a recent project I was working with iQ.Suite from GBS and specifically the component of this software that add signatures to emails. The client are an international organization with users in different geographies and we needed to accommodate the users qualifications in their email signature.

The problem with this is that in Germany qualifications are written in front of the name and in the USA at the end and in other countries at the start and the end. We were doing a Notes to Exchange migration and in Notes the iQ.Suite signature software read data from Notes that was originally pulled from Active Directory, and so the client had placed the qualifications in the DisplayName field in the Active Directory.

But when we migrated to Exchange Server the Global Address List listed the users DisplayName an so the German users where all listed together with “Dipl” as the first characters of their name. Also the name the email came from was written like this. The signature worked, but the other changes that became apparent meant we had to work out a different way to look at this problem.

So rather than using DisplayName for the users name and qualifications, we used personalPrefix in Active Directory to store anything needed before their name (Dipl in the above German example, and Prof or Dr being English examples) and the generationQualifier Active Directory attribute to store any string that followed the users DisplayName (such as Jr in the USA or BSc for qualifications etc.)

In iQ.Suite we created a signature that looked like the following. This has a conditional [COND] entry for personalTitle, displayName and generationQualifier. That is if each of these are present, then show the displayName with personalTitle before it and generationQualifier after it. If the user does not have values for these fields, do not show them. The [COND] control is documented in iQ.Suite.

[COND]personalTitle;[VAR]personalTitle[/VAR] [/COND][COND]displayName;[VAR]displayName[/VAR][/COND][COND]generationQualifier; [VAR]generationQualifier[/VAR][/COND]

What was not so well documented, and why I wanted to write this blog entry was that the personalTitle and generationQualifier attributes are not stored in the Global Catalog and so are missing in the users signature. In the multi-domain deployment we had at the client, iQ.Suite read the personalTitle, displayName and generationQualifier Active Directory attributes from the Global Catalog as Exchange was installed in a resource domain and the users in separate domains and so unless the attribute was pushed to the Global Catalog it was not seen by iQ.Suite.

To promote an attribute to be visible in the Global Catalog you need to open the Schema Management MMC snap-in, find the attributes of question and tick the Replicate this attribute to the Global Catalog field. This is outlined in