Fixing Office 365 DirSync account matching issues
15 August 14 05:14 PM | dmstork | 0 Comments   

Recently I had to fix some issues with DirSync. For some reason (there were some cloud users created before DirSync was enabled) there were duplicate users, because DirSync failed to match the already present cloud user and the corresponding AD (Active Directory) user. There were also accounts that failed to sync and thus failed to sync all attributes properly.

If there is already a cloud account and there is need for a synced account, you can create an AD account in DirSynced OU's. But be sure to create the user with a full UPN matching the one in Office 365 and SMTP addresses that are present on the Cloud account. With the next sync it should match both accounts. If not, it fails matching and you end up with either duplicate accounts (one cloud user and a DirSynced user with the same name/lastname/displayname) or get an InvalidSoftMatch.

When UPN/SMTP matching failed you can merge those accounts again by setting the ImmutableID on the Office 365 account (MsolUser) which is derived from the AD user’s ObjectGuid. You can only add this attribute to Office 365 accounts. After this is set, DirSync should match the accounts correctly.

So, how did I resolve this? See below:

When there are duplicates:

  • Remove user from DirSync (move to OU which is not synced, will only work when OU Filtering is used. If not, disable DirSync…).
  • Perform DirSync.
  • Remove duplicate synced user (NOT cloud user):
    • Remove-MSOLuser -UserPrincipalName <UPN> -RemoveFromRecycleBin
    • Add ImmutableID from AD user to Cloud user
      • $guid = (get-Aduser <username>).ObjectGuid
        $immutableID = [System.Convert]::ToBase64String($guid.tobytearray())
      • Connect to AD Azure (Connect-MSOLService when AD Azure Powershell Module is installed).
      • Set-MSOLuser -UserPrincipalName <clouduserUPN> -ImmutableID $immutableID
      • It's possible that the clouduserUPN must be changed to the <tenant>.onmicrosoft.com format. It should be changed by DirSync to correspond with the AD UPN.
      • See also http://www.joseph-streeter.com/?p=423
  • Place account back in correct (synced) AD OU.
  • Manually kick off a sync on the DirSync Server if you don’t want to wait (up to 3 hours with default settings):
    • C:\Program Files\Windows Azure Directory Sync\DirSyncConfigShell.psc1
    • Start-OnlineCoexistenceSync

In my case it didn’t always match the accounts and was required to perform a Full DirSync (on DirSync server):

    • Via MIISClient, Management Agents:
      • C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\missclient.exe
    • Be sure to be member of local group "FIMSyncAdmins"
      Names might be different depending on DirSync version
    • On the Windows Azure Active Directory Connector:
      • Properties>Run>Full Import Delta Sync
    • on the Active Directory Connector:
      • Properties>Run>Full Import Full Sync
  • Note that a Full Sync can take a long time if you have a lot of objects. Furthermore, changes can take a while to propagate in Office 365.
  • It might be necessary to edit an attribute (Description, office etc. Something that is synced), and then perform a (normal) sync.

 

When you have an InvalidSoftMatch (SMTP Address matching doesn't work because SMTP address already exists in Cloud):

Within the MIISClient.exe on the DirSync server, you can check for errors. In this case the account wasn’t properly matched:

clip_image001

  • Add ImmutableID from AD user to Cloud user:
    • $guid = (get-Aduser <username>).ObjectGuid
    • $immutableID = [System.Convert]::ToBase64String($guid.tobytearray())
    • Connect to AD Azure (Connect-MSOLService when AD Azure Powershell Module is installed)
    • Set-MSOLuser -UserPrincipalName <clouduserUPN> -ImmutableID $immutableID
    • It's possible that the clouduserUPN must be changed to the <tenant>.onmicrosoft.com format. It should be changed by DirSync to correspond with the AD UPN.
    • See also http://www.joseph-streeter.com/?p=423
  • Then perform a sync as described in the previous section.

In my case these procedures resolved my issues. But as always, use this information at your own risk. Best to make sure that you don’t end up in a situation like this Winking smile

See also:

One or more objects don't sync when using the Azure Active Directory Sync tool http://support.microsoft.com/kb/2643629/en-us

How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization http://support.microsoft.com/kb/2641663/en-us

Filed under: ,
Optimizing the Outlook AutoDiscover process by skipping the root domain query
13 August 14 11:42 AM | dmstork | 0 Comments   

Updated 8/15/2014: see the bottom of this article for additional information on changed AutoDiscover behavior of Outlook 2013.

Consider the following scenario:

  • An Active Directory (AD) domain named equal to the SMTP Suffx, so the mailaddress dmstork@contoso.com in the contoso.com AD domain.
  • No on-premises Exchange, this means that there is no Service Connection Point (SCP) in A.
  • Outlook 2013 (or lower versions from Outlook 2007 up).
  • Exchange Online (or any hosted Exchange for that matter).
  • Additional issue: You’ve got an external website that responds to HTTPS requests and doesn’t have a valid certificate for the root domain. This happens quite a lot, especially when the intent is to redirect to www.contoso.com

In these cases the AutoDiscover proces will detect the domain has no Exchange (because no SCP) and will at first try to connect to https://contoso.com/Autodiscover/Autodiscover.xml. However, because the domain is the same as the SMTP suffix of the primary SMTP the IP’s of the Domain Controllers are returned. That part is as expected, if you look in your domains DNS there are (pinpoint) records on the contoso.com that contain the IP addresses of each DC. It could mean that the initial setup of Outlook can take a while to complete as it waits for an AutoDiscover response. If you have quite a few DC’s, it’s possible Outlook will retry the request for each entry. And each entry will have to time-out (about 20 seconds) before skipping to the next entry.

When this process hasn’t resulted in successfully attaining configuration settings, Outlook will try other options and eventually it will be configured to be connected to the correct Exchange environment at expected speeds.

To resolve this, install the Office 2013 Administrative Templates. If you still use Office 2007 or 2010, you should install the corresponding version (and Service Pack level), however I haven’t checked whether they have the setting I wanted to show you.

After installation, create a new or edit an existing GPO and go the the following User Configuration setting:

Administrative Templates>Microsoft Outlook 2013>Account Settings>Exchange>Disable AutoDiscover.

Check the option “Exclude the root domain query based on your primary SMTP address”.

image

In one situation we reduced the duration of the AutoDiscover process from 45 seconds (or even failure to complete) to 12 seconds.

Skipping the root domain during the AutoDiscover process, will also resolve the issue when you have a webserver listing on the root domain and that server responds to HTTPS request without having a valid certificate for the root domain. Even if the AD root domain does not correspond to the primary SMTP domain. I’ve seen this a couple of times, were the organization site would redirect to www.contoso.com when the root domain is visited via browser. If the certificate isn’t valid, Outlook will generate a certificate mismatch warning and requires user interaction, which IMHO defeats the purpose of AutoDiscover. In cases that the certificate cannot be adjusted for whatever reason, this would be a good alternative for domain joined computers.

For non-domain joined computers the use of an GPO isn’t possible, but extracted the correct key from the registry might work. You would only need to deploy the setting via other means. Please remember that each version of Outlook requires a separate registry key (if the option is available at all).

For Outlook 2013 this would be (copy and paste to a .reg file and doubleclick on the computer/user that needs this fix. Note (and remove) the extra linefeed after "software\"):

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\software\
policies\microsoft\office\15.0\outlook\autodiscover]

"excludehttpsrootdomain"=dword:00000001

Disclaimer: the use of this information is at you own risk, you can comprise the correct working of the computer you apply this fix on. Test this before deploying in production!

My thanks to coworker Hans for the regkey information.

Update 8/15/2014: Fellow Exchange MVP Paul Cunningham pointed out some changed behavior of Outlook 2013, which now simultaneously queries the SCP *and* the SMTP root domain. This can result in certificate issues. Exchange MVP Andrew Higginbotham wrote about it here. 

Managing Mailbox quota’s: databases with different settings?
01 August 14 06:18 PM | dmstork | 0 Comments   

So, a while back I discussed an on-premises Exchange design for a customer. When discussing database distribution in an Exchange 2013 Database Availability Group (DAG), the topic of mailbox quota’s came along. They insisted on having different Database (DB) level quota’s and move mailboxes to other databases when the user requires more storage space.

It’s a tactic I have seen before, especially during Exchange 2003 (Enterprise edition) and Exchange 2007. I can understand why organization adopt this practice, it’s easy to implement and relatively easy to administer. But I prefer a different approach, one that has less technical issues and is simpler from an infrastructural viewpoint.

The problem with quota tiering of DB’s is that it requires mailbox moves when a higher quota is necessary. That generates extra transaction logs, but also generates white spaces in the DB’s with lower quota’s. Luckily transaction logs are purged after a successful full backup, but you have to take the extra necessary space into account. The same goes for white spaces. Yes, it will be re-used for new mail, but it’s still storage you won’t win back immediately, unless you perform a database rebuild. Something I wouldn’t recommend on a regular basis.

Another thing to consider is that the amount of quota sizes is limited to the amount of DB per server. In 2010/2013 Edition Standard that is 5 DB’s, which is hopefully not an issue. What might become an issue is the amount of storage used per database. Microsoft recommends maximum database sizes of 200GB and 2TB, the first size is for an single DB the latter one if the DB is protected within a DAG. Do note that these are recommendations, depending on your situation it could very well be prudent to keep the DB’s smaller due in order to keep restore times in line with you Service Level Agreement. In any case, this will immediately affect the amount of mailboxes that you could keep in a database and it could result that you would have no more in order to keep with this practice with Exchange Standard edition and thus upgrade to Exchange Enterprise Edition which has the ability to mount up to 100 DB’s.

Also, there might be a correlation between mailbox size and mailbox activity; a more active mailbox will probably reach it’s quota more quickly. So, concentrating those mailboxes in the same database might give rise to higher IOPS for that specific database with larger quota mailboxes. Even though the Exchange Server Role Calculator can be used enter up to four different mailbox type usage, but it assumes all mailboxes are randomly spread out all DB’s. I won’t suspect any issues from this, but it is certainly something to take into account.

So, I prefer to set the same default quota setting on all databases. It’s a much more simple approach, especially when using a DAG. I consider the DAG mostly a big data black box and don’t care where the mailbox is located. This way you can profit from the automatic mailbox provisioning introduced in Exchange 2010, which load balances the placement of mailboxes across databases unless excluded. This way all mailbox activity and storage is leveled out over the available databases and thus they should all behave relatively the same. Which I reckon would simplify admin life in the long run, more so than the benefits of having database quota’s.

If there is a need to increase the quota beyond the established default quota value, I would set it on the mailbox directly. Especially with the Exchange Management Shell (EMS), you are much more flexible. You can even schedule a task with a script that checks group memberships or custom attributes (for instance) periodically and adjusts that mailbox quota according to specific requirements. This way you still have an easy or even automatic method increasing a mailbox quota, but without the previously mentioned downsides.

Exchange mail flow not working? Check your (Cisco) firewall!
06 July 14 08:49 PM | dmstork | 0 Comments   

I’ve come across this issue several times: External mail (or mail between Exchange servers) cannot be delivered, however when you check with telnet the Exchange server(s) are responding. When you check via telnet on the external IP you get something similar:

image

In this case it was a Cisco ASA firewall that had (E)SMTP filtering feature (also called Mailguard) enabled, which is the default setting.

Unfortunately, this feature filters very strict and blocks extended commands that are allowed by RFC5321 which are used by Exchange.

The feature also blocks SMTP TLS connections, which is used in Exchange hybrid configurations which uses Strict TLS for mail flow between on-premises servers and Office 365.

To resolve this issue, disable the (E)SMTP filtering feature on any device that in some way handles SMTP traffic (don’t forget those in between Exchange sites of your organization!). That’s it!

/edit 20140707:My coworker PaulM provided me with an screenshot on how to disable this feature. Thanks!

Configuration > Firewall > Service Policy Rules > Default inspection policy:

CiscoSMTPFiltering_thumb[1]

Filed under: ,
I am now an Exchange MVP!
01 July 14 09:03 PM | dmstork | 1 Comments   

For those who weren’t following me on Twitter (or Facebook or whatever), today I received an important mail:

image

Dear Dave Stork,
Congratulations! We are pleased to present you with the 2014 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Exchange Server technical communities during the past year.

After checking headers for spoofing etc. (hey! It’s my expertise after all Winking smile ), I was honored, overjoyed, flabbergasted, excited, inspired, humbled, motivated and a lot of other emotions at the same time.

It’s a welcome recognition of my endeavors (not only this blog) which I do for my own enjoyment, but also for others such as peers, coworkers and the community as a whole. I intend to continue my current efforts and I am excited at any new opportunities in the future.

But I probably wouldn't have reached this point, if it wasn’t for a whole lot of people. And of course I want to take this opportunity to thank them (hope I don’t forget anyone): Sander Berkouwer (coworker in crime) for getting me to start blogging, my employer OGD for giving me a lot of freedom and opportunities, my coworkers with all their suggestions and questions, the UC Architects gang for all those interesting discussion, all who sent me mails with questions, and, of course, my blog/Twitter/LinkedIn/Facebook readers/followers.

And last but certainly not the least: my wife Valesca. Thanks for putting up with me. Winking smile

Filed under: ,
Legacy Public Folders to Exchange 2013 migration tips
30 June 14 06:14 PM | dmstork | 1 Comments   

A couple of weeks ago I performed a Public Folder migration from Exchange 2007 (aka legacy) towards the modern Public Folders of Exchange 2013. As you may know, the traditional migration method using Public Folder replica's isn't available due to a radical redesign of the Public Folder architecture. Instead of dedicated databases, the hierarchy and data are now stored in mailboxes. The biggest benefit is that Public Folders can now be protected via a Database Availability Group, the downside is that the multi-master model is now defunct as only one DB copy can be active one server in one location.

The radical redesign also means that the migration process is vastly different. Microsoft has done it's best to describe the process via this article. However, as always, there are some gotchas you might encounter along the way. While I was in the process of migrating, I tweeted my progress using the hashtag #PFMigrationWatch. This post is for on-premises deployments/migrations, although some tips might be valueable in either cases. 

But let’s take a look at the required steps (the numbers correspond with the numbers from the article) and I’ll add some helpful tips not mentioned in the article:

  1. Download the scripts.

    Well, that’s easy. You have to have the scripts on a legacy server (i.e. 2007 or 2010) and the 2013 server. Some you will use on the legacy servers, other only on the Exchange 2013 servers.

  2. Export the current structure, statistics and permissions of the legacy public folders in order to verify the migration. Perform this on a legacy server. 

    If you had plans to clean up you Public Folders, do this beforehand! Or use the provided information, but rerun these scripts again after clean up. Furthermore, these can take a long while to complete, depending on the amount of public folders and customization. Better plan this some time before the actual migration, but not too long as the organization might require changes that won’t be recorded. You could inform the organization that a feature freeze has occurred and temporarily change some permissions. Discuss this with the organization.
    Next to inventory important PF information, you should also check on trailing spaces or backlashes in the Public Folder names and remove them. Otherwise the migration might not start or fail.
    As a final check, look whether there has been a migration request submitted already or if there are already Public Folders present on the Exchange 2013 server. If the latter is the case, you have to remove them (probably best to save the information, unless it’s clear it can be deleted without issue).
    Remember; if you have multiple Public Folder databases, wait for replication of all changes before moving forward.

  3. Generate CSV files

    Now you will create CSV files that will determine the distribution of your Public Folders within the Public Folder Mailboxes. The first script (Export-PublicFolderStatistics.ps1) will create an inventory on how large each folder is. The second script (PublicFolderToMailboxMapGenerator.ps1) determines which folder will be located in which mailbox, based on the CSV output of the previous script. This is presented in the mapping file, it basically says which folder and/or subfolders are placed in which public folder mailbox. How it is distributed will be dependent on the maximum mailbox size you will enter. It is possible that a main folder is in Mailbox1 and some of the subfolders in Mailbox2. User won’t notice this, as Exchange will present the whole hierarchy as if it were in one location.
    Please note the Public Folder limits, you can find the most recent limits here. For this particular step the follow limit is important: each Public Folder mailbox must not exceed 100GB (soft limit), but to allow growth be sure to enter a lower number. With this particular migration I had 5 databases, so I divided the total amount of Public Folder storage by 5 (the number of databases) in order to get a nice distributed scenario with each database containing a Public Folder Mailbox. In this case it left more than enough growth for each mailbox.
    Unfortunately, it seems as if some of the limits of Modern Public Folders are lower than what has been expected. Although Microsoft has announced upcoming increases of limits, do check for them before going forward and take action when required. It might be necessary to clean up even more and redo steps 2 and 3.

  4. Creating Public Folder Mailboxes in Exchange 2013. Perform this on an Exchange 2013 server.

    This is quite simple, just remember to use the same mailbox name as what is used in the mapping file from the previous step. You can change the names in the mapping file if required, as long as they correspond with the names you use in this step.
    Remember to create the mailboxes in the correct database or move the mailbox afterwards. Furthermore, don’t forget to set adequate mailbox quota’s. If you do not, the Public Folder mailboxes will default to the database quota settings which are probably a lot less than required for Public Folders. If you do not set it correctly, users possibly cannot edit/add items and mail will possibly be bounced. Luckily the migration will continue and will be completed, even if the quota has been reached during this process.

  5. Start the Migration request

    This is the first initial synchronization of the hierarchy and data from legacy to modern public folders. Users will still be able to access legacy public folders (also from 2013 mailboxes).
    Be sure to monitor the progress regularly, there are several reasons a request might fail. Too many bad items, for instance. Or too large items, which would result in the error code TooManyLargeItemsPermanentException. You can monitor the request with:

    Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport

    If you forgot to configure those values at the start, don’t panic. Just change the request and add the parameters afterwards (with Set-PublicFolderMigrationRequest using the identity of the existing but suspended/failed request) and then rerun the same migration request again (by Resume-PublicFolderMigrationRequest). Note that setting/raising the BadItemLimit or LargeItemLimit still doesn’t force migrate those items, but it means the request will continue despite encountering issues (which are skipped). Check the report of the migration request to see which items are affected. Especially with large items, I tend to copy them out of the legacy public folder for safe keeping. You could check whether the TransportConfig MaxReceive size setting is something you want to adjust to a higher value, but I hadn't had the need in this particular case. 

  6. Lock down legacy Public Folders

    Now the real migration begins! When the legacy Public Folders are locked, no one can access Public Folders legacy or modern. User might experience credentials pop-ups in Outlook. So, this is something for a maintenance window and requires informing you users.
    Furthermore, mail-enabled folders won’t receive mail anymore. That mail will be queued and delivered when the migration will be finalized. So, keep an eye on those queues and the amount free disk space of the legacy servers!

  7. Finalize migration

    Immediately after locking down the folders, you can finalize the migration. How long this will take depends on the amount of changes since the initial replication that have to be migrate. You can perform delta synchronizations (as long as the migration request parameter PreventionCompletion is $true) with:

    Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

    This is ideal if you want to prepare the Public Folder migration a relatively long time ahead of the actual migration, while keeping the finalization time to a minimum. Especially with large and/or highly active Public Folder implementations this is a way to keep downtime to a minimum.
  8. Test and unlock modern Public Folders

    So, now everything is over, data, permissions and whether a folder is mail enabled (and thus mail addresses) are all migrated. And yes, the mail flow for mail-enabled folder is immediately active after the migration has been finalized in step 7 (that means mail flow from your legacy mail servers to Exchange 2013 should’ve been working before finalizing). 
    You can now check whether everything has been migrated properly, perhaps using the exports made in step 1. You might want to consider letting some key users test it. Before unlocking it for the organization, you can unlock the modern Public Folder on a per mailbox basis. Do note that any changes (don’t forget mail enabled Public Folders!) aren’t replicated back to legacy folders, take that in mind if you require a rollback.

So that’s it. It’s not a completely painless operation, but the Microsoft article is clear and adequate even if it’s missing some tips I’ve mentioned. In some regards I feel as if I have more control compared to the legacy Public Folder replication. Smile

Let me know if you have additional tips!

Office 365 users can't see free/busy of on-premises users
05 June 14 07:16 PM | dmstork | 0 Comments   
The past few days I was working on making an on-prem Exchange Server 2013 SP1 environment hybrid with the Office 365 tenant. You would expect that running the Hybrid Configuration Wizard (HCW) would be it, after setting all the requirements as they should.

Unfortunately after running the HCW, Office 365 mailboxes couldn't access free/busy information of on-prem mailboxes. The other way round was functional. Enter troubleshooting mode! I will spare you the whole story and summarize it to the basics.

I did get an AutoDiscover error after finishing the HCW the first time, but subsequent runs did not give me the error:

Office 365 was unable to communicate with your on-premises Autodiscover endpoint.  This is typically due to incorrect DNS or firewall configuration.  The Office 365 tenant is currently configured to use the following URL for Autodiscover queries from the Office 365 tenant to the on-premises organization - https://autodiscover.contoso.com/ autodiscover/autodiscover.svc/WSSecurity. See the following article for further information: http://go.microsoft.com/fwlink/p/?LinkId=275838

Inspecting the environment also didn't show up any issues and the Exchange Remote Connectivity Analyzer also did not show any issues. Not with AutoDiscover and not with the Exchange Web Services (EWS). Both crucial in these endeavors. I found some posts that setting WSSecurityAuthentication on the AutoDiscover and EWS virtual directory should be True and that even if the value is already set to True reapplying it would possibly help. Unfortunately not for me.

Running Test-OrganizationRelationship on the "On-Prem to O365" object did show some errors, but after consultation probably weren't the cause of this issue. However, when running the same test on the "O365 to On-prem" object (using remote PowerShell to the Office 365 tenant), the test failed on AutoDiscover (excerpt):

STEP 3 of 4: Requesting delegation token from the STS...

RunspaceId  : 2a0844db-1337-4b35-993b

Identity    :

Id          : AutodiscoverServiceCallFailed

Status      : Error

Description : The Autodiscover call failed.

IsValid     : True

ObjectState : New

Terminating execution. Autodiscover service call failed.

This error prompted me to perform an IISreset on all on-prem Exchange servers, even tho ExRCA showed everything was fine. After finishing, I ran the OrganizationRelationship test on "O365 to On-prem" again and this time it completed successfully! Checking with my O365 mailbox now showed Free/Busy information of on-prem mailboxes. Victory!

Lesson learned: Have you tried turning it off and on again?

Despite the fact I resolved it myself: thank you to all that tried to help me!

From open source groupware solution Zarafa to Exchange: Part 2, Active Directory
25 May 14 11:01 PM | dmstork | 0 Comments   

See also Part 1: A New Beginning

When using Zarafa there are several possible directory services you can use for authentication. I will restrict this post to situations relevant to Active Directory (AD) integration. Even if you did not use Active Directory (or Zarafa for that matter) previously, I believe this post still contains valuable information.

Getting to know your current environment is key if you want to change it. If you migrate from one version of a product to another, this is important, but if you change the vendor of a certain solution, a lot of extra information is crucial. It is very possible that specific information isn’t automatically transferred as it would with a migration of products from the same vendor, like an Exchange to Exchange (intra-forest) transition.

This post shows you what and how to inventory relevant AD information and in some cases even provides tips to prepare those objects for an Exchange implementation. In these situations, there is already an out-of-the-box Exchange 2013 server present in the same Active Directory. In my experience that shouldn’t be an issue and it makes an inventory much easier. As a best practice, I also install the Remote Server Administration Tools (RSAT) with the Active Directory PowerShell module on each Exchange server.

AD Objects

It is important to know what objects are used and in what way. Be certain you have inventoried the following objects:

  • Distribution Groups
  • Users
  • Contacts
  • Public Folders

If you have a domain joined computer with PowerShell, use it to extract this information from AD (with the exception of Public Folders). An alternative is CSVDE which can also export this information to a Comma Separated Value (CSV) file, usable in scripts or a spreadsheet program like Excel for further analysis.

Note:
Be sure to use the CSVDE -u unicode parameter if you have an international organization with international characters in Displaynames.

When integrated with AD, Zarafa is able to use the objects stored in it.

   

Distribution groups 

This means that if you used Distribution Groups within Zarafa you can reuse them for Exchange without recreating them. This has several advantages:

  • You don’t have to recreate groups 
  • Users that are accustomed using specific groups don’t have to change their behavior when selecting the correct group.

Do note that Zarafa does not require these groups to be of the Universal scope as it is required with Exchange. But, luckily, you can change this scope easily via Active Directory PowerShell. The example below converts all Global groups with the “DL_” prefix to the Universal Scope:

Get-ADGroup -Filter {(name -like "DL_*") -and (GroupScope -eq "Global")} | Set-ADGroup -Groupscope Universal

Furthermore, at least in earlier Zarafa builds, these groups do not necessarily have to be mail-enabled and might not have a SMTP address (which made using them from an ActiveSync client via the Zarafa ActiveSync Z-Push add-on impossible, by the way…). In Exchange this is required and when you mail-enable these groups they will receive an SMTP address. Configure your Exchange Email Address Policies (EAP) to meet your SMTP needs, specific for groups. And if those groups were used to grant permissions in any way, they need to be Security Distribution groups and not plain Distribution groups. You can do this via Active Directory and Computers (ADUC) MMC or when bulk changes are required via the Active Directory PowerShell with:

Set-ADGroup –Identity <name> -GroupCategory Security

Note that the Exchange Admin Center (EAC) doesn’t provide the option to mail-enable existing groups. You’ll have to do that via PowerShell. The example below first stores all Universal groups with prefix “DL_” in a variable and then mail-enables them:

$adgroups = Get-ADGroup -Filter {(name -like "DL_*") -and (GroupScope -eq "Universal")}

$adgroups.name | Enable-DistributionGroup

$adgroups.name | Set-DistributionGroup -HiddenFromAddressListsEnabled $true

Adjust this example to your needs. By storing the groups in a variable, you can modify them further with Set-DistributionGroup. In this example they also are hidden from the Global Address List (GAL). Be sure that you have implemented your EAPs before performing this action, otherwise these groups might get SMTP addresses you didn’t want (you could clean them up afterwards, but that’s extra work. And you know, us IT people are kinda lazy ;-) ).

Users and contacts can also be reused by Exchange, but be sure to configure Email Address Policies correctly according to your SMTP standardization. Be sure to check these policies AND your AD naming convention. As many Exchange and AD experts know, AD is quite US-focused and does not provide room for non-US naming conventions. It might be necessary to make changes in AD in order to get the most out of your EAP. Now, no AD naming convention will be perfect, but I would suggest you'd use a convention that will allow EAPs to generate the bulk of you SMTP addresses correctly. That will save administrative effort.

 

Public folders

Public Folders are a special breed. This is the case within Exchange, but certainly also within Zarafa. Most importantly, they cannot be mail-enabled within Zarafa. This provides us with important challenges. If you needed to direct mail into a Public Folder within Zarafa, you need to use something like Procmail to move specific mail into the folder. This means SMTP addresses are outside Zarafa and you have to examine several rules in order to determine which Public Folders will have to be mail-enabled within the Exchange environment.

That is, if you want to keep Public Folders... There are scenarios were you’d rather want Shared or Resource mailboxes. You will have to inventory and probably interview users of those specific folders in order for you to determine what to do with them. This is actually something I also do when migrating Exchange to Exchange (2010+).

On a side note, do remember that Public Folders in Exchange 2013 are no different from previous versions of Exchange from a user perspective (except that you are limited in OWA 2013…) but the infrastructure is vastly different. Be sure to read up this topic even if you have Exchange knowledge but just not up-to-date.

AD attributes

As Zarafa has a different philosophy regarding storing information, it is very likely that not all attributes are stored in AD. Having a more modular setup, one can use a transport service of their own choice. Postfix for instance. However, it is possible to have address rewrite rules on this SMTP entry point that will never show up in AD attributes.

Because of this, it is paramount to check you whole mail flow infrastructure for any rewriting. For instance, one costumer had contoso.com as default mail address in Zarafa and Postfix rewrote every SMTP address with a specific country TLD, such as contoso.nl, to contoso.com. However, as Exchange correctly doesn’t allow duplicate SMTP addresses, I prefer to keep all SMTP logic within Exchange. It’s easier and less prone to errors to manage all SMTP addresses within Exchange because your mail environment is less complex.

But let’s focus on what’s in AD. As said, Zarafa can integrate with Active Directory and even adds new application specific attributes, but also uses default properties.

Some are used differently, most important the mail address attribute. Below are screenshots of the Zarafa attributes added to a user account when performing an Zarafa schema update:

Zarafa AD Attributes on an non-mail(box) enabled user.Zarafa AD Attributes on an non-mail(box) enabled user.

Most of the attributes make sense and, although I didn’t require this information when migrating, you could extract information from AD and use them again for Exchange mailboxes. That is, if it is required to have exactly the same values in the Exchange equivalent attributes. It shouldn’t be to hard to script this.

Do notice that in the Zarafa fields, no SMTP address fields are present. This is because it uses the default fields already present in AD, namely:

  • mail
  • otherMailbox

See an example below. The first screen show the mail field, which corresponds with the Emailadress field in the Account tab (because this a production environment I have redacted specific customer information):

E-mail address in the General tab corresponds with mail attribute 1 of 2E-mail address in the General tab corresponds with mail attribute 2 of 2

Within Zarafa the “mail” field is read and used for the primary SMTP address of the specific user, however in Exchange this field is *written* by Exchange and should not be changed by an admin. Remember this when you implement Exchange and Zarafa side by side in the same Active Directory forest! Before you Exchange Mail(box) enable an user, be sure that the Email Address Policies will hand out the exact same primary SMTP address, otherwise you could break mailflow while Zarafa is still in production.

So, what about otherMailbox? It is how Zarafa handles multiple mail addresses besides the primary SMTP address. Exchange does this via the ProxyAddresses attribute. Below is an example showing a user which was Zarafa *and* Exchange mailbox enabled and had multiple addresses (again customer information redacted):

Use of otherMailbox by Zarafa and proxyAddresses by Exchange

This example has a SIP addres as it was also Lync enabled, but be sure that it contains all the SMTP address as in use with Zarafa. Again preferably with the help of Email Address Policies.

To summarize it in a table:

image

Mail contacts and mail enabled groups, basically, work with the same principles shown here. As user mailboxes are most critical and most complex, I’ve focused my attention on these objects in this post.

Concluding

Luckily, in most cases you can re-use the same objects and mail(box) enable them in Exchange. Zarafa and Exchange can be implemented in the same AD forest (during migration), but there are some gotchas.

In some cases the groups used most be converted to another scope and be security enabled. Zarafa doesn’t make this distinction, Exchange does.

Zarafa handles the primary SMTP address somewhat differently than Exchange and good care has to be taken regarding Email Address Policies when mailbox enabling users who are also Zarafa Mailbox enabled. Be sure that the primary SMTP within Zarafa is the same as in Exchange.

Furthermore, additional addresses are stored in another AD Attribute (otherMailbox) than what Exchange uses (proxyAdresses). These should be re-entered, preferably with Email Address Policies.

Mail enabled Public Folders are probably the most work when migrating, as Zarafa doesn’t has the concept of Mail-enabled folders and thus nothing of the relevant data is stored within AD but rather on external solutions (in most cases Procmail).

See also Part 1: A New Beginning

Behind the presentation: Office 365 apps
20 May 14 08:09 PM | dmstork | 0 Comments   

Last Monday evening I presented “Office 365 apps” for the Dutch NGN-NGI interest group. And obviously the presentation was interesting, I think a little behind the scenes look for this particular presentation is worth a blog post. Actually, they might complement each other!

So, I was asked to present something about apps on an Office 365 themed event. That was basically the assignment and please notice the very broad scope it could have. That was the first challenge.

The first thing was to determine how I would present this. I had about an hour and while you could discuss all aspects of apps, I think it could be much more exciting and insightful to have live demo’s. But those kinds of presentations are quite risky compared to just a PowerPoint slides only presentation. I had to prepare this and have back-up plans for each dependency… the second challenge.

Obviously the Office suite would be part of it, but there are certainly other applications. The first one that came to mind is obviously OWA for Devices, as it has something to do with Exchange. Currently it’s only available for iOS, but an Android version will be here soon (no Windows Phone version announced though, Tony Redmond talks about this app here. Insightful read IMHO).

But as all the application basically require Office 365 access (like duh), I was also dependent on internet access and the quality of the connection. That was the third challenge…

Devices, devices, devices

In any case, it became apparent that for a decent presentation on Office 365 apps I had to approach it with multiple devices. Every ecosystem has their own set of apps and from an user perspective, it’s important to know what you can do with each of those devices (and apps for that matter).

My demonstration setup with all devices (except for my Windows Phone)I already have a Windows 8.1 laptop, a Surface RT 8.1, a Windows Phone 8.1 and an iPad 2 with iOS 7. To represent the Android ecosystem I chose to buy a very cheap tablet with 4.1.1 on it, the Yarvik Noble 7c. It cost me about €60, so for a demo tablet this would be okay.

Presenting

As I was unknown to the location, this prompted my to try and get all screen information of my devices on my laptop. This way I was ensured that I had the option to use HDMI, DisplayPort or plain old D-Sub. That would limit cable switching hassles and connector issues.

For Surface RT I couldn’t use RDP or anything like that, but it has a fine micro-HDMI output. Previously I bought an micro-HDMI to full HMI adapter *and* an HDMI to VGA converter cable. Not all venues have HDMI, mostly it’s D-Sub only. Because I installed the Windows Phone 8.1 developer preview on my phone, I could use the Screen Projection feature. My Nokia Lumia 920 doesn’t support it in combination with Wi-Fi, so I used an USB cable. This was my only option.

For the iPad I used an trial edition of AirServer, which did the trick neatly. It uses the AirPlay functionality of your iPad, so no Apps on your device except for the Windows machine. Airplay uses Wi-Fi. As a backup I purchased the VGA cable (not the HDMI, as I expect D-Sub to be the standard).

And for the Android ecosystem I’ve used BBQScreen. It can use either Wi-Fi or the USB cable, the former is easier to use. The Android app itself costs €2,99, which is acceptable. The tablet had an mini-HDMI output, which I could use in the event the app wouldn’t work. I bought an mini-HDMI to HDMI adapter just in case.

Do note that every solution with Wi-Fi requires your presentation device (my laptop) to be in the same network in order for it to work. I assumed the location would have Wi-Fi, an reasonable assumption as it is the main office of an IT services company. But because I’m an pessimist, I had also an backup for internet connectivity: my phone with tethering. As it was near Amsterdam, I hoped I would get a fast 4G connection.

This is me starting my presentation. Picture by Jaap WesseliusI’ve tested all solutions in various combinations during the days leading up to the big day. All issues that I’ve encountered had been fixed and I was ready for it!

Oh right, I do have make some sheets to introduce the subjects and stuff. Let’s not forget that! Smile

Zero Hour

As I was the first presenter, at arrival at the scene I immediately started to setup my gear. I wasn’t familiar with the possibilities of the site, but I was relatively confident I had thought of everything and had backups for the issues I didn’t think about.

But the first hurdle presented itself immediately: they only had HDMI connections and no VGA/D-Sub. Well, that eliminated my iPad VGA adapter backup Sad smile. AirServer was my only option and as Office for iPad was IMHO the most important non-Windows “Office 365 app” I wanted to demonstrate, I was getting a bit nervous.

So, after getting Wi-Fi credentials and setting up my devices and testing them, I noticed I couldn’t get AirServer and BBQScreen to connect to my devices… It hit me: most public Wi-Fi setups are (and should be) configured with AP isolation, meaning connected devices cannot “see” each other. Security wise a wise choice, but it didn’t help me.

I had to initiate my backup: phone tethering. Luckily this didn’t have AP Isolation so I could connect to my devices and present as planned. I even had 4G, but it doesn’t have bandwidth guarantees and I was getting a bit more nervous. The initial test I did at that moment, showed that I could open documents etc.. 

Now my setup was up and running, I decided to check whether the beamer could handle everything. During my tests at home, I noticed that my monitor couldn’t handle the resolution the iPad VGA adapter provided. I hoped this would be an issue here. But unfortunately it was!

My Surface RT’s resolution wasn’t something the beamer couldn’t handle, extending didn’t work so mirroring was the only option. Downscaling the resolution was the only option to get something without distortion, but it meant that I couldn't start Modern Apps. Luckily that wasn’t my goal, Office 2013 RT is a desktop app which doesn’t have that issue. Pffieuuwww Smile

After this test, I had to start the presentation. All issues I already encountered were no issue. Me (in a very healthy posture, ahum) demonstratint Android applications. Picture by Jaap WesseliusBut then I started both the Windows Phone projection and the AirServer application on my laptop. These aren’t windowed applications, but use the full screen. It appeared that this was an issue with extended desktop and thus with presenting it on a beamer. Eventually I did manage to get their image on the beamer but don’t ask me how! But I can tell you that were some tense and very very long seconds!

Despite these challenges, the actual presentation went pretty well considering (IMHO). Even the demos did what they had to do, but unfortunately downloading documents was sometimes too slow due to the 4G connection via my phone. But that is a risk even with the best internet connection available. I improvised and mentioned that this is a downside of using cloud services: dependency on internet connectivity and bandwidth. When life gives you lemons… Open-mouthed smile

So, this was it! Looking back this was technically the most challenging presentation I've ever given, but because of that it was also quite gratifying. I’ve took a lot of time in order to make sure my demonstrations went as smooth as possible. And I hope that the audience got a good glimpse of what apps are available for the three ecosystems: that was the goal of this presentation and the live demos.

Most important lesson presentation wise: have tested backup plans in place!

Does your Office 365 DNS records check fail?
15 May 14 12:12 PM | dmstork | 0 Comments   

Recently I was working on building an hybrid Exchange 2013 environment. During the setup for specific mail domains, Office 365 didn’t seem to see the DNS records required. In this case it was the SPF record, that would not be accepted.

image

However the record was made as specified as requested, TTL was an hour and after several hours it still didn’t pass the check. Other records made at the same time, were checked okay. Unfortunately that delayed other required changes…

Checking somewhat closer I found the culprit: the actual TXT value was:

v=spf1 include:Spf.protection.outlook.com –all

Do you see it? Yes, it seems the Office 365 DNS record check is case sensitive… I don’t know how it became a capital S, but in any case: when they mean exactly, they mean EXACTLY…

Correcting this “typo” resolved the issue quickly and I could continue with other changes. So if your DNS records check fails, check the case!

Sidenote: This also means you cannot have any deviations in your SPF record, when this check is performed. Take that into consideration, it can impact your specific mail flow design or other services that should be allowed to mail.

Filed under: ,
Disable Offline OWA in Exchange 2013
30 April 14 05:37 PM | dmstork | 1 Comments   

Although the Offline OWA functionality in Exchange 2013 is a great addition for those that cannot use Outlook (Anywhere with Cached Mode), but are frequently without internet. However, as the browser database in which Exchange OWA stores it’s information isn’t encrypted, it can be a security issue.

It can be turned of via the Exchange Admin Center (EAC) via Permissions>Outlook Web App Policies and then edit the policies by double-clicking them. Navigate in the pop-up window to Offline Access and specify your required setting.

image

Via the Exchange Management Shell you have to use the Set-OwaMailboxPolicy cmdlet. The parameter is AllowOfflineOn, but the possible values aren’t really intuitive or correspond with those visible EAC. But checking the TechNet page of the cmdlet, we can find PrivateComputersOnly (offline only available when logged in as private. OWA assumes private as default, you can enable the public computer option), NoComputers, or AllComputers which is default.

To disable Offline OWA completely for the mailboxes using the Default OWA Policy use the following:

Set-OwaMailboxPolicy -Identity Default -AllowOfflineOn NoComputers

To disable Offline OWA for all currently present OWA policies use:

Get-OwaMailboxPolicy | Set-OwaMailboxPolicy –AllowOfflineOn NoComputers

You could use a separate policy for those mailboxes that do require Offline OWA and assign that policy to the mailboxes.

MEC 2014 Meta recap
28 April 14 01:25 PM | dmstork | 0 Comments   

For those that weren’t at the Microsoft Exchange Conference 2014 in Austin, there is a ton of information now available. It certainly won’t compare to actually have attended this conference, but it’s better than nothing. I’ve probably forgotten a ton of other information, but you gotta start somewhere Smile

Channel 9

Most recordings are now available for free at Channel 9. See here for all MEC2014 content. If you want to download all the stuff, use this script tweaked by Peter Schmidt 

Check out some these sessions that are IMHO a good start:

Exchange and Office Team Blogs

The Exchange and Office teams have published several blogs that are tied in with announcements and sessions made during MEC2014.

Blogs

Several MVP/MCMs and trusted Exchange blogger have made some posts about MEC 2014 (in random order).

I don’t have anything to add on what was has been said in these posts. You could call me lazy, but I call it least administrative effort Smile

The UC Architects

Obviously The UC Architects were present and we even recorded a live session! The Episode 36 recording is available on our site and in several stores. More MEC related content was discussed in the follow-up recording in Episode 37.

Filed under: , ,
Next week I'll be at the Microsoft Exchange Conference 2014!!!
24 March 14 09:17 AM | dmstork | 1 Comments   

The Microsoft Exchange Conference 2014 will start in a week! As with the previous version I’ll be there too! For those attending, this is my MEC2014 profile (login required).

I’ll arriving Saturday late evening and I’ll leave the next Saturday in the afternoon. Unfortunatly no solo sessions, but I will certanly be there for The UC Architects Live session (code: ARC.IN.306 currently planned on wednesday afternoon)! Between the official event parties etc., ENow will also sponsor a The UC Architects party!!! Registration is required and can be done here: http://schedulemymaintenance.com/. To increase your chances to attend, listen to The UC Architects podcast episode 35 and check the promo code mentioned in it. You’ll certainly see me at this social event and a lot others.

 

For those who are interested, but do not attend; be sure to check my Twitter account @dmstork as I will undoubtedly be tweeting a lot of information. Expect important, less well known, interesting and breaking shiny new facts! If you have a question, feel free to tweet me and I'll see if I can answer your question myself or ask the speaker.

For those who don’t want a barrage of Exchange related tweets, it’s probably best to block/filter. Official event hashtags is #iammec, but expect a lot of #MSExchange as well. I’ll probably will blog about the event as well, but probably afterwards and not during.

I hope to see you there! 

 

 

Filed under: , ,
Updated - Exchange 2013 DAG, Windows Server 2012 R2 and VMware vSphere? Check support!
21 March 14 11:28 PM | dmstork | 1 Comments   

UPDATED 28/3/2024: See update below article.

A little heads up. While working on an extensive design including Exchange Server 2013 with Service Pack 1 installed on Windows Server 2012 R2, my eye caught a comment in the Facebook group Exchange Server 2013 (Facebook login required).

VMwares vSphere 5.1 and higher are shown to be validated by Microsofts Server Virtualization Validation Program (SVVP) to run Windows Server 2012 R2 VM’s. The hypervisor needs to be validated also as a requirement for virtualizing Exchange Server 2013. So far so good.

But you’re not there yet, the Microsoft Clustering on VMware vSphere: Guidelines for supported configurations (1037959) from VMware has a small footnote for this specific combination of Exchange and Windows OS. It’s only supported from vSphere 5.5. This is something that is easily missed (yeah, I would've missed it too if it weren’t for my procrastination on Facebook Smile). See the screenshot below with highlighting the specific sections (Click to enlarge image).

Click to enlarge image

I’ve discussed this with an VMware vExpert and although he didn’t know any specifics, it might have to do with some improvements for low-latency applications specific for vSphere 5.5. New features in 5.5 might also explain why for Windows Server 2012 it is stated that (among others) a DAG does not require explicit support statements from VMware.

Luckily we are still in the designing phase, so we can and will take this into consideration (either upgrade vSphere or use Windows 2012 R1). Even if it would work, I wouldn’t want to take the risk ending up in an unsupported situation (from VMware). Especially considering that when you implement a DAG, high availability of Exchange servers is something that is on your mind.

This is a good reminder to always thoroughly check support from all vendors before implementing the newest builds and versions.

UPDATED 28/03/2014: We submitted a VMware support ticket with this issue. Their answer clarifies the statements made in the KB: The combination 2013 DAG on Windows Server 2012 R2 hasn't been tested by VMware on other than vSphere 5.5, but it certainly doesn't mean that other combinations won't work. Either way, their support also stated that an explicit support statement isn't required from VMware when we decide to use vSphere 5.1 in this situation instead. That is in line with the support statements in the KB article for Windows Server 2012 RTM and it makes me feel more comfortable to go forward (without vSphere 5.5). But don't believe me at my word; I would advise to submit a VMware support ticket if you also want an explicit clarification directly from VMware.

Be careful with Outlook customizations! Use AutoDiscover!
20 March 14 09:24 AM | dmstork | 0 Comments   

During a migration from Exchange 2007 to 2013, we moved several mailboxes as pilot users. Coexistence was fully configured and on my test machine everything worked fine. However, the pilot users had trouble connecting with Exchange 2013 after their mailbox was successfully moved to Exchange 2013 servers. OWA and ActiveSync worked without any hitch.

The problem was that Outlook would update its server settings, even though (internal) AutoDiscover worked perfectly. Outlook seemed to retain its settings for Exchange 2007, which shouldn’t be the case. Due to architectural improvements in Exchange 2013, Outlook server setting isn’t a servername or CAS array FQDN anymore but a mailbox unique GUID combined with a @ + UPN suffix. Obviously this is not a server that Outlook can connect to, but as Exchange 2013 now always uses Outlook Anywhere externally and internally it that isn’t an issue. However, you can’t easily change those server settings as you would have to determine the specific GUID which can be a hassle for a servicedesk. So, Outlook really requires AutoDiscover to set server settings.

After investigation we determined that the Office 2010 deployment had customizations in place from the Administrative Installation Point, including hardcoded server settings towards the Exchange 2007 server environment. As it seems, these settings were so pervasive that a mailbox move to 2013 didn’t correctly update. Even when we forced (try, try again and when you don’t succeed use a hammer) and Outlook could connect to Exchange 2013, some features were still broken (OOF settings, for instance. Which relies on Exchange Web Services). A brand new profile seemed to mitigate all issues.

AutoDiscover was introduced with Exchange 2007 and was supported from Outlook 2007 and forward. Therefor it’s a mystery why the server settings were deliberately set in customizations. It might have been prudent during the Exchange 2003 days (which will end in about a month when mainstream support ends), but it’s unwise in combination with Exchange 2007, very unwise with Exchange 2010 (especially when you have site resiliency plans) and just plain st*pid with Exchange 2013. It’s not only there for initial setup, but also for any High Availability/failover plans you might have.

If you find the initial Outlook setup screens requiring user interaction by pressing Next and then Finish annoying, which even appear when connecting with a domain joined computer, you can let Outlook skip those by using the Office/Outlook GPO Administrative Templates specific for your version of Office. Enable the “Suppress recommended setting dialog” in the GPO (source). More general info here (specific for Office 2010).

TL;DR: don’t customize/script Outlook to connect to a predefined Exchange server. Be smart, let it use AutoDiscover.

Thanks to coworker SanderV for his investigation!

More Posts Next page »

Search

Go

This Blog

Syndication