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!

The UC Architects Episode 35: Service Packed! is available now!
18 March 14 08:22 AM | dmstork | 0 Comments   

A few days ago episode 35 of The UC Architects podcast went live! Service Packed!

With Steve Goodman hosting, joined by John Cook, Michael Van Hybrid, Michel de Rooij, Serkan Varoglu, Ståle Hansen and yours truly. Our editor was the legendary Andrew Price. In this episode we talk (a lot) about Exchange Server 2013 Service Pack 1, a quick review of the new features and the detected Transport bug and how we feel about that one. If you have plans to upgrade, be sure to check this part out!

Personally I’m happy with the new features and fixes of SP1 (even SSL Offloading, although Steve made some very good counterpoints), but the transport bug is kind of a downer although I wonder how many organizations would be impacted. Luckily Microsoft delivered a fix quickly, be sure to install it right after SP1. No re-issue of SP1 will be made, a permanent fix will be present in CU5.

We also talk about other Exchange updates, Office Web App 2013 Service Pack 1. Some important new scripts, Modern Public Folders and it’s limits. And a lot about authentication via ADFS and Multi Factor Authentication options in SP1 and in combination with Windows Azure. There is also some Lync news about several new tools. One topic is the ability to assign static IP addresses to Azure VMs, which led me to question whether it was the first step in supporting the new Exchange 2013 Edge role in Azure. It was part of a more general line of thought, some application would surely benefit from static IPs. This feature could be the step to officially support those applications within Azure, making it more mature. Because around the same time Exchange 2013 SP1 was released with the re-introduced Edge role, which is probably why my mind associated them both together.

And for those who are going to the upcoming Microsoft Exchange Conference in a few weeks, not only can you enjoy a live recording of an episode but if you wish to attend our UC Architects party sponsored by ENow, listen to the podcast carefully. You have to register @ http://schedulemymaintenance.com/ and in this podcast there is a mention of a promo code which increases your chances of admittance very much. Attendance is limited, stop reading my post and listen to this episode!

You can download the episode here, on the same page links relevant to this episodes topics are listed.

Exchange 2013 SP1 is out! And now?
27 February 14 12:22 AM | dmstork | 0 Comments   

Fireworks are seen over the Olympic Cauldron during the opening ceremony of the 2014 Winter Olympics in Sochi, Russia, Friday, Feb. 7, 2014. (AP Photo/Julio Cortez)Yesterday the Exchange Team finally released Exchange 2013 Service Pack 1 (SP1). And even as promised within early 2014! Nothing like a major release to get those blog writing blocks lifted Smile.  
Download SP1 here and see their blog here. Be sure to check out the release notes and the What’s New page.

So, what now? Hopefully many of you have installed previous Cumulative Updates (CU). But even if you haven’t (although I hope you’re not still stuck with CU1 or Zeus forbid RTM), you could right away install SP1 on top of your Exchange 2013 servers without installing previous intermediate cumulative updates (the name really is a clear hint isn’t it?). And although this update is called Service Pack 1, it’s technically Cumulative Update 4.

Features

Can we expect some new features? Sure! Let’s take a closer look to some of the features:

  • Windows Server 2012 R2 Support
    Now we can install Exchange 2013 SP1 directly on Windows Server 2012 R2. Not only that, it is now also supported to have 2012R2 domain controllers and a 2012R2 Forest Functional level. But remember: in-place upgrade from 2012 RTM to 2012 R2 when Exchange is installed is not supported (way way back with Exchange 2000 and 2003 was the last time that was possible). If you want 2013 SP1 on 2012R2 you need to re-install it. When you do that, also remember that Exchange servers in a DAG (Database Availability Group) should be of the same Windows OS (even if Exchange 2013 can support different builds within a DAG).
  • Edge Transport Servers
    Back again! This is not something I was very eager for, I haven’t installed much Edge transport servers with 2007 and 2010. But if you had one of those, now you can upgrade it so all Exchange servers can be a 2013 build.
  • Junk Email Reporting in OWA
    OWA (Outlook Web App) users can now report junk mail or false positives in OWA and the Microsoft Spam Analysis Team will analyze and take action accordingly. You will only benefit from this if you use Exchange Online Protection with your on-premises Exchange 2013 SP1 servers. I do wonder whether this information is also used by SafeList aggregation.
  • S/MIME for Message Signing and Encryption
    Never had the pleasure of implementing this security feature, but now the world is becoming more conscience about prying eyes I think it is a welcome addition. However, I think that Office 365 Message Encryption is more admin and user friendly (sender and receiver) but not all organizations can implement that (due legal restrictions etc.). Still only for Internet Explorer though…
  • Data loss prevention (DLP) improvements
    There are several improvements, most visible is the inclusion of Policy Tips in OWA and OWA for Devices which was a important downside IMHO. Document Fingerprinting is also an interesting addition.
  • AD FS claims-based authentication with OWA and EAC
    Now multi-factor authentication solutions for OWA and EAC (Exchange Admin Center) are possible due to the integration with Active Directory Federated Services (AD FS). However, this is only possible with Exchange 2013 SP1 servers, no co-existence is possible even with Exchange 2013 RTM.
  • SSL Offloading in Exchange 2013
    Finally official support for SSL offloading on all virtual directories. Especially those with Load Balancers with encryption accelerators will be happy, although if you use Content Switching in your load balancer (see my or Michael van Horenbeecks excellent post) it is also a very welcome addition! Unfortunately, configuration  is not possible via EAC or EMS (Exchange Management Shell). You need to use appcmd, except for Outlook Anywhere (Set-OutlookAnywhere) and Mailbox Replication Proxy (MRSProxy, for cross-forest mailbox moves. It has no offloading, you need to use SSL Bridging).
  • DAG without an administrative access point, Dynamic Quorum/Witness
    Tired of creating CNO’s by hand? Do you also forget to provide a static IP to you DAG? Well, that’s over now with Exchange 2013 SP1 on Window Server 2012R2. There are also some other improvements due to enhancements made in 2012R2. If you have a DAG with 2013, be sure to check out Scott Schnoll’s excellent post about the changes.
  • MAPI over HTTP
    A new communication protocol designed for this new (mobile) age. Even though Outlook Anywhere has got us this far, it’s an old protocol designed to work around downsides of the RPC protocol. It’s not enabled per default and for now only Outlook 2013 Service Pack 1 supports it. Check out Tony Redmond’s very clear and informative post about this new change and why you might want to enable it. I hope that Outlook 2013 RT on my Surface RT will support it Smile
  • Command Logging
    Not to be confused with Audit Logging. In Exchange 2010 you had a very educational and helpful (documentation) feature in the EMC, a PowerShell preview in which you could see, learn and copy cmdlets and one-liners. Unfortunately with the introduction with the web based EAC, that feature was gone. Although it’s not a preview, this Command Logging is still a welcome addition. See a post about it from Jaap Wesselius and Jetze Mellema (dutch).

Seeing this list of new features, it’s easy to forget there are also bug fixes. See a list here. I won’t go into them, but I have encountered some issues that are now resolved. Pfffeeuw Smile 

Installing

You might be very eager to install it right away, but I would take the path of caution. It’s still possible some nasty bugs are present in SP1, even though the Exchange Team has undoubtedly done is best to prevent those. But it has happened. So, I tend to wait for about two weeks and keep watching the blogosphere. When possible I also use that time to test SP1 in a lab environment, preferable as close as production environment as possible.

So, ready to install? What do you need to know? Basically it’s the same as with every 2013 CU. As always, check out the Release Notes there is helpful information present. I’ll highlight some of the most important gotcha’s below.

With this update, an Active Directory Schema Update is required. Plan this accordingly, especially if you have separate responsibilities.

Unfortunately the web.config files are still overwritten (insert sigh). So if you have customized them, which is the case when you have Lync IM integration in OWA, you need to re-apply those changes after updating Exchange. Do NOT reuse the previous configuration file, as with each update there are also crucial additions which otherwise would be lost. Edit the new configuration file.

Don’t forget to update (non US) UM Language files if you are using UM. You’ll probably triggered while trying to install SP1 as it prompts to remove them to continue. But still better to be prepared. Download the necessary Exchange 2013 SP1 Language UM files here.

Please note that mail flow can be “broken” after SP1 installation. You can restart the Microsoft Exchange Frontend Transport service, but I feel more confortable to restart the server after a CU or in this case SP1 installation. For more information about this issue see the posts from Paul Cunningham and Michel de Rooij.

When you are finished with the Exchange bit, don’t forget to update Office 2013 to SP1 (for MAPI over HTTP) and Office Web Apps Server 2013 with it’s SP1 if (when) you use it with the Exchange 2013 OWA Web Preview. The same goes for SharePoint Server 2013 which also saw it’s SP1 released, although I haven’t seen any changes regarding Site Mailboxes. Be sure to check this blog post of the Microsoft Office Sustained Engineering Team with all the Office updates and links.

Related

In a related note; Microsoft also released Exchange 2007SP3 RU13 and 2010SP3 RU5. For 2007SP3RU13 it’s a minor fix mentioned in KB2917522 (Edge 2007 publishing issue with Exchange 2010). The list for 2010SP3RU5 is a bit longer as listed in KB2917508.

Download links

Download Exchange 2013 Service Pack 1 (SP1)
Download Exchange 2013 Service Pack 1 (SP1) UM Language Packs
Download the Microsoft Office 2013 SP1 32-bit package
Download the Microsoft Office 2013 SP1 64-bit package

Download SharePoint Server 2013 Service Pack 1 (SP1)
Download Office Web Apps Server 2013 Service Pack 1

Download Exchange 2007SP3RU13
Download Exchange 2010SP3RU5

From open source groupware solution Zarafa to Exchange: Part 1, A New Beginning
24 January 14 12:01 AM | dmstork | 1 Comments   

This blog series will describe my experiences and lessons learned from migrating the Zarafa Groupware solution to Microsoft Exchange, specifically Exchange Server 2013. I've done this twice now and although some things are quite obvious, there are some gotchas and it might be a daunting endeavor. A normal transition from Exchange to Exchange already requires good planning, but it is even more important when migrating from a third party solution that isn't supported by any available migration tool like Quest. I hope that with sharing my experiences, others will have a more smooth migration and happy users. Even if you don't use Zarafa, most information will still be relevant when migrating from other (somewhat obscure) groupware systems or even from Exchange.

This part 1 post will give an overview of relevant topics in the upcoming posts.

See also Part 2: Active Directory

Goal

The goal of the migration is to migrate existing mail from Zarafa to Exchange, in such a way that users will have the most smooth transition possible. Having said that, there will be changes in how users have to use Outlook. There will certainly be some downtime, there will probably be some (meta-) data loss and users will certainly have to reapply some of their settings, after they have been migrated. As an admin, it's important to acknowledge these things and prepare yourself and the organization for these changes. This will be discussed more extensively in a next part of this series.

Zarafa

But first, a little introduction of Zarafa Groupware. It's a Microsoft Exchange Server alternative; an open source community software suite that mimics Microsoft Exchange. It runs on top of Linux-based Operating Systems, but can be integrated with Microsoft Active Directory. Users can connect via its webmail, use ActiveSync via the open source solution Z-Push, and can use Outlook via a plugin provided by Zarafa. It's my understanding that it's relatively popular in Europe, because some (government) organizations prefer or are required to use open source software unless closed source solutions are proven to be a better fit.

Zarafa is the core product, but it requires other open source solutions for mail flow. Organizations are free to use some of those supporting products, which makes it flexible. But it also means it's not one big application with everything in it, and it requires admins to be knowledgeable about Postfix, Procmail and other solutions. There are multiple areas and programs where settings are required, in order to make the whole solution work as required. Where as you can administer practically everything within Microsoft Exchange, this is not the case with Zarafa, even when it's integrated in Active Directory. You could compare it with Microsoft Exchange Server 5.5 in some regards.

Whether it's cheaper or not, is something that I have debated regularly, but for now that is beyond the scope of this series. Zarafa can be compared with other like-minded solutions like Zimbra and OpenXchange, so as said some parts of this blog series could apply to those (and other) solutions.

I've migrated from Zarafa version 6.4 and 7.0 to Microsoft Exchange Server 2013 (first time to RTM and second time to CU3).

Exchange 2013

The target solution will be Microsoft Exchange Server 2013. While most actions described will be valid for Microsoft Exchange Server 2010 and perhaps even Microsoft Exchange Server 2007, the 2013 version certainly has it's own issues to take into account. Having said that, the focus will not be how to successfully implement Exchange Server 2013, unless there are issues specific to this migration scenario.

Overview

There are several aspects of this migration that are important enough to be blogged about. As time (and writing) goes by, they might (probably) change but as for now expect posts regarding these topics:

  • Inventory
    Know what you have, what's relevant and how it works, otherwise you can't know how to reach the end goal.
             
  • Active Directory
    How Zarafa integrates in Active Directory, which attributes are used by Zarafa and challenges.
            
  • SMTP Mail flow and objects     
    Things to take into account when functionality from Zarafa and it's MTA's (Mail Transfer Agents) are converted towards Exchange.For instance, Zarafa doesn't have mail-enabled Public Folders.
             
  • Client Access & Coexistence     
    Coexistence with different Exchange versions isn't always easy, but most scenario's are described by Microsoft or other bloggers. This isn’t the case with this scenario and I’ll show the impact and some possible choices.       
           
  • Migration and Export/Import of data
    How do you get user and public folder data from Zarafa towards Exchange and expected challenges. Expect the use of PST files.
             
  • Communication to users 
    Users will need instructions on how to survive the transition and to know what to expect. This is much, much more important than when you transition from Exchange to Exchange.
            
  • Planning & Concluding remarks
    Now you know what to do and how to do it, you can plan all necessary steps. Additional I probably have some concluding remarks, tips and tricks.
            

Concluding

Now you have a bit of an idea what to expect from this series.

If you already have some questions, remarks or even suggestions for additional topics, feel free to let me know via a comment or other means of communication.

See also Part 2: Active Directory

More Posts Next page »

Search

Go

This Blog

Syndication