Updated DirSync can now be deployed on a Domain Controller.

Microsoft recently released a new version of Windows Azure Active Directory Sync, better known as DirSync. As the information on the Version Release History page of the tool depicts, this new build allows you to deploy DirSync on a Domain Controller.

Along with this new ability, this new version (6553.0002) also includes some fixes:

  • Fix to address Sync Engine memory leak
  • Fix to address "staging-error" during full import from Azure Active Directory
  • Fix to handle Read-Only Domain Controllers in Password Sync

The latest version can be downloaded from the following page:

Have fun!

Blog Office 365

Exchange Online Archiving (EOA): a view from the trenches – part 1

What is Exchange Online Archiving?

I’ve been meaning to write this article for quite a while now, so I’m glad it’s finally “ready”. First, let me start by introducing what Exchange Online Archiving (EOA in short) actually is.
This feature, first available since Exchange Hybrid, allows you to provision an cloud-based archive for an on-premises mailbox. While having an Exchange archive isn’t something new, at least not since Exchange 2010, the fact that the archive doesn’t have to be hosted within your own organization is pretty interesting.

Archives can be useful in many ways. One of the primary reasons why archives are used is to keep historical data for a longer period of time without cluttering a user’s primary mailbox. This could, for instance, be the case when you have to meet some compliance requirements which e.g. state that corporate data should be kept for 5 years. Although Exchange doesn’t have a problem with handling very large mailboxes including a high item count per folder, it’s usually the human component that cannot handle the overload of information that comes with having large amounts of data – at least that’s my experience. Keeping email inherently means that you’ll have to increase disk space to support the sometimes huge amounts of data that is involved. Although disk space has become quite cheap and Exchange 2013 is a great candidate to be used in combination with those cheap disks, there’s still a significant overhead involved in keeping that additional piece of infrastructure up and running.

This is where Exchange Online Archives could come in handy. First of all, there is no feature difference between an on-premises archive or a cloud-based (Office 365) archive. From a user’s point-of-view they both act and look the same. In fact, you are only offloading the task of storing archives to Office 365. The Exchange Online Plan 2 subscription automatically includes the right to provision unlimited-sized archives for your users. Although I don’t expect many people to run into the issue of filling up the initial 100GB, which you get provisioned to start with, any time soon, it’s very hard to match that offer for only  8$ per user per month… If you are only interested in EOA, there are specific EOA licenses as well which cost only a fraction of the full Exchange online license. Of course, this license will only allow you to use EOA and nothing more.

How does it work?

As briefly touched upon earlier, being able to use Exchange Online Archives is a by-product from having a hybrid Exchange deployment. A hybrid deployment, as the name stipulates, is the process of ‘pairing’ your On-Premises Exchange organization to Office 365; essentially creating one large “virtual Exchange organization”. As a result, having a (fully functional) Hybrid Deployment is the first requirement to abide to… Technically speaking it would be possible to setup a sort of minimalistic Hybrid deployment in which you leave out functionalities that you do not necessarily need to make Online Archives work (like e.g. cross-premises mail flow). Nonetheless I strongly encourage to still setup the full monty. It might save you some time afterwards if you decide to deploy cloud-based mailboxes anyway.

A very import part of the setup is set aside for DirSync. As you might remember, if you tick the “Hybrid Deployment” checkbox during DirSync setup, you allow it to write back some attributes into your on-premises organization. One of these attributes is the msExchArchiveStatus attribute. This attribute is a flag telling the on-premises organization whether an online archive has been provisioned or not. As we will see later in this section, this attribute is particularly important during the creation of an archive.

One of the questions I get asked regularly is whether you are required to deploy ADFS when setting up a hybrid deployment. The short answer is no. On the other hand, there are many good reasons why you would want to deploy ADFS, or rather: there are many good reasons why you would want to have some sort of single/same sign on. One reason I can think of it to simplify using online archives from an end user’s perspective. That way they won’t need to manage another set of credentials. Of course this isn’t only valid for online archives, it’s the same for each cloud-based workload in Office 365. ADFS can be one way of providing SSO, Password Sync is another. Both are valid options, neither are required and won’t be discussed here.

From a functional point-of-view, Online Archives have the exact same requirements as on-premises archives. You at least need Office 2007 SP3 Professional edition or later. Since we are running archives from Office 365, you also need to make sure to be up to speed with the latest required updates. For more information on what updates are needed, have a look at the following web page: http://office.microsoft.com/en-us/office365-suite-help/software-requirements-for-office-365-for-business-HA102817357.aspx

Now that we got the prerequisites covered, let’s have a look at how the provisioning process works from a high-level perspective:

image

As you can derive from the image above, there are two DirSync operations needed. The first one is used to “tell” Office 365 to create an archive for user “X”. The second DirSync operation is used to sync back the msExchArchiveStatus attribute which will now have a value of 1 instead of 0. This is to tell the on-premises organization the archive has been created. A good way to verify whether this process has completed is to run the Get-Mailbox | fl *arch* command:

image

Here you can see that the archive was created successfully (ArchiveStatus = Active). However, we are missing a part of the information. This is because the on-premises organization cannot provide the information from Office 365 (which is essentially another Exchange organization). To fetch the missing information, you’ll have to open up a remote PowerShell session to Exchange Online and run the Get-MailUser | fl *arch* command:

image

Conclusion

This is it for part one of this article.
In the following part, I will talk about some of the gotchas, do’s and don’ts. Stay tuned!

Exchange Exchange 2013 Hybrid Exchange Office 365

Create a function to connect to and disconnect from Exchange Online

[Update 26/03/2013] I wanted to share a quick update to the script with you. Over the past few weeks, I have hitting an issue at some customers that used an outbound authenticating proxy which prevented me from connecting to Exchange Online using the functions from my profile. As such, I have tweaked the script a bit to now include a switch (-ProxyEnabled) that, when used, will trigger PowerShell to authenticate the session against the proxy.

The new script now looks like this:

[sourcecode language=”PowerShell”]
function Connect-ExchangeOnline{
[CmdLetBinding()]
param(
[Parameter(Position=0,Mandatory=$false)]
[Switch]
$ProxyEnabled
)

if($ProxyEnabled){
$Session = New-Pssession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential (Get-Credential) -Authentication Basic -AllowRedirection -sessionOption (New-PsSessionOption -ProxyAccessType IEConfig -ProxyAuthentication basic)
}
else{
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Authentication Basic -AllowRedirection -Credential (get-credential)
}

Import-PSSession $session
}

function Disconnect-ExchangeOnline {
Get-PSSession | ?{$_.ComputerName -like "*outlook.com"} | Remove-PSSession
}
[/sourcecode]

[Original Post]

Office 365 allows you to connect remotely to Exchange online using PowerShell. However, if you had to type in the commands to connect every time, you would be losing quite some time:

[sourcecode language=”powershell”]$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri <a href="https://ps.outlook.com/PowerShell">https://ps.outlook.com/PowerShell</a&gt; -Authentication Basic -Credential (Get-Credential) -AllowRedirection

Import-PSSession $session[/sourcecode]

Equally, to disconnect, you’d have to type in the following command each time

[sourcecode language=”powershell”]Get-PSSession  | ?{$_.ComputerName -like "*.outlook.com"} | Remove-PSSession[/sourcecode]

However, it is relatively easy to add both commands into a function which you can afterwards add them into your profile:

[sourcecode language=”powershell”]Function Connect-ExchangeOnline{
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri <a href="https://ps.outlook.com/powershell">https://ps.outlook.com/powershell</a&gt; -Authentication Basic -AllowRedirection -Credential (Get-Credential)
Import-PSSession $session
}

Function Disconnect-ExchangeOnline{
Get-PSSession  | ?{$_.ComputerName -like "*.outlook.com"} | Remove-PSSession
}[/sourcecode]

To add these functions to your PowerShell profile, simply copy-past them into your profile. To find out where your profile-file is located, type the following:

PS C:\> $profile
C:\Users\Michael\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

To start using the functions, all you have to do is to call them from the PowerShell prompt:

PS C:\> Connect-ExchangeOnline

cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential

WARNING: Your connection has been redirected to the following URI:
https://pod51014psh.outlook.com/PowerShell-LiveID?PSVersion=3.0

PS C:\> Disconnect-ExchangeOnline

Note   there is no output for the Disconnect-ExchangeOnline function

How-To's Office 365 PowerShell

How to check what the version of your tenant is in the cloud (Office 365)

I sometimes get the question how one can verify what the version of Exchange they’re running in the cloud. Although it should be pretty obvious based on the GUI (Exchange 2010 vs. Exchange 2013) and the fact that the latter isn’t generally available yet, it could come in handy once it does. According to some sources, the release might be sooner than later.

Additionally, when you’re planning on going hybrid with the new version of Exchange in Office 365, you’ll have to make sure your tenant isn’t in the process of being upgraded and is running version 15.

To check the version, open up a PowerShell session to your Office 365 tenant and run the following command:
[sourcecode language=”powershell”]Get-OrganizationConfig | ft AdminDisplayVersion,IsUpgradingOrganization[/sourcecode]
With the command for connecting to Office 365 via PowerShell, that would look something like this:
[sourcecode language=”powershell”]$session = New-PSSession –ConnectionUri https://ps.outlook.com/powershell –AllowRedirection –Authentication Basic –Credential (Get-Credential) –ConfigurationName Microsoft.Exchange

Import-PSSession $session

Get-OrganizationConfig | ft AdminDisplayVersion,IsUpgradingOrganization[/sourcecode]

Running these commands would then lead up to a result similar to the following:

Get-OrganizationConfig | ft AdminDisplayVersion,IsUpgradingOrganization -Autosize

AdminDisplayVersion IsUpgradingOrganization
------------------- -----------------------
0.10 (14.16.190.8)                    False
How-To's Office 365

You get an error: “The <name> connector cycle has stopped. Object with DN <GUID> failed…”

As part of setting up a hybrid configuration between Exchange on-premise and Exchange online (or when configuring Exchange Online Archiving), you also need to setup DirSync.

In these scenarios DirSync fulfills an important role as it will also configure the write-back of some attributes in your local Active Directory. This “write-back” is required for Hybrid/EOA to work. For a list of attributes that are sync to/from Office 365, have a look at the following article: http://support.microsoft.com/kb/2256198

As part of the best-practices when installing DirSync, you should always run the Office 365 Deployment Readiness tool which will scan your local Active Directory and search for incompatible objects. The tool will create a report in which incompatible objects are mentioned. This will allow you to modify these object before configuring DirSync.

However, sometimes object can still contain incompatible object attributes, which might cause issues for DirSync. In such case, you’ll likely be presented with the following error in the application event log. Please note that this example mentions an issue with the “TargetWebService” Management Agent. It could very well be that you’ll encounter an issue in the SourceAD Management Agent.

The TargetWebService Connector export cycle has stopped.  Object with DN CN=<guid> failed validation for the following attributes: proxyAddresses. Please refer to documentation for information on object attribute validation.

This error contains 2 important items:

  1. The Distinguished name (CN=<guid>)
  2. The attribute that is causing issues

However, matching the guid to a user-account isn’t very easy. The best way to go about is to open the MIIS Management Interface and work from there. Usually, the client can be found in the following directory:

C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell

image

After opening the client, navigate to Management Agents, right-click the management agent mentioned in the error message and select Search Connector Space:

image

In the “Search Connector Space” window, select DN or Anchor from the drop-down list under Scope and specify the Distinguished Name from the error message. Afterwards, click Search:

image

The search should return a single object. Double-click it to view additional information. Search for the attribute that was mentioned in the event log entry to review its value(s):

image

In this particular case, one of the proxy addresses contained an illegal character which caused the Management Agent to fail. Once you determined what the issue was, correct the value in AD and re-start synchronization. Normally, synchronization should happen successfully now.

How-To's Office 365

Error: You cannot synchronize the ADFS configuration database after adding a secondary federation server

Introduction

There are multiple ways to setup a highly available ADFS server farm. One possibility is to install multiple federation servers using the default Windows Internal Database.
In that case, the first federation server is designated as being the ‘primary’ federation server. Every subsequent federation server that is added to the farm will be a ‘secondary’ federation server.

These secondary federation servers periodically poll the primary federation server for configuration changes and replicate these changes across. By default this is every 5 minutes.

This scenario is especially useful if you do not have a SQL server available or if you cannot make your SQL server highly available but still want to increase resiliency for your federation server farm.

Note   when using the Windows Internal Database instead of SQL, you are limited to a maximum of 5 federation servers in a farm.

If you want more information, read my previous article on the implications of a database choice in ADFS:

The issue

When installing a secondary federation server, you might see the following error in the AD FS 2.0 Application Event Log when the server tries to contact the primary federation server to replicate the configuration database:

EventID: 344
Source: AD FS 2.0s

There was an error doing synchronization. Synchronization of data from the primary federation server to a secondary federation server did not occur.

Additional data

Exception details:
System.IO.InvalidDataException: ADMIN0023: Incorrect value for property LastPublishedPolicyCheckTime: 12/31/1899 11:00:00 PM.
   at Microsoft.IdentityServer.PolicyModel.PropertyTypes.DateTimeProperty.Validate(Object context)
   at Microsoft.IdentityServer.PolicyModel.PropertyTypes.PropertySet.ValidateProperties(Object context)
   at Microsoft.IdentityServer.PolicyModel.Client.ClientObject.GetData()
   at Microsoft.IdentityServer.PolicyModel.Client.ClientObject.OnReadFromStore()
   at Microsoft.IdentityServer.PolicyModel.Client.SearchResult..ctor(SearchResultData data, PropertyFactoryBase factory)
   at Microsoft.IdentityServer.Service.Synchronization.SyncAdministrationManager.DoSyncForItems(List`1 itemsToSync)
   at Microsoft.IdentityServer.Service.Synchronization.SyncAdministrationManager.Sync(Boolean syncAll)
   at Microsoft.IdentityServer.Service.Synchronization.SyncAdministrationManager.Sync()
   at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.SqlPolicyStoreService.DoSyncDirect()
   at Microsoft.IdentityServer.Service.Synchronization.SyncBackgroundTask.Run(Object context)

User Action
Make sure the primary federation server is available or the service account identity of this machine matches the service account identity of the primary federation server.

image

The solution

In this specific case, the customer decided to geographically spread the different AD FS servers to increase the (site) resiliency of their federation server farm. However, this particular secondary federation server was located in a different time zone than the primary federation server. It seems that AD FS cannot handle the time zone difference by itself (unlike e.g. Active Directory that reduces time back to UTC).

After changing the time zone on the secondary AD FS server to match the time zone of the primary AD FS server, replication started working.

ADFS Blog Hybrid Exchange Office 365

Update: Disappearing (online) archives after moving your mailbox to Office 365

Update

After a few weeks of mailing back and forth with Microsoft’s support, I was today (finally) able to confirm that the issue which I described below is now solved.

It seems that Microsoft rolled out a hotfix/code change for their Exchange Online service. Although, at first, I thought the issue was related to a bug in EMC for not correctly issuing all parameters when initiating a remote mailbox move, it seems the issue had more to it than that. Basically, what happened is that when MRS moved the mailbox from on-premises environment to Office 365, it wouldn’t keep the link to the already-existing archive. This caused a new (empty) archive to be created and could possibly cause data loss.

I’m happy to see what time and effort Microsoft has put into solving this issue. It proves that Microsoft is concerned about the quality of their product / service. In fact, it would surprise me if they weren’t. A bug that could cause data-loss is not really something you’d want to carry around for a long time!

Thanks to everyone involved and kudo’s to Philippe Phan Cao Bach (Sr. Escalation Engineer) who was working with me on this case.

Original Post

Office 365 offers great ways to enhance the functionalities of your on-premises deployment. By running the Hybrid Configuration Wizard (which Steve Goodman explains in this article) you can configure both environments to act as one; allowing you to make use of features such as e.g. Online Archives (EOA).

With Exchange Online Archives, your primary mailbox stays in your on-premises Exchange server, whereas the archive will – as the name might have given away – be hosted in Office 365. If you’re interested in finding out more about Online Archives, I suggest that you take a look at Bharat Suneja’s session at TechEd this year: “Archiving in the cloud with Exchange Online Archiving

The problem

To me, one of the most interesting things about a hybrid deployment is the flexibility it offers. You can put a few mailboxes in Office 365, try them out and move more to the service if you like it.

If you are looking to take that approach, this information might be interesting for you!

Imagine the following: you are trying out Office 365 and decide to use Online Archives to start with. You provision the archives and life is great! After a while you decide you want to use more and you decide to move some mailboxes to Office 365. However, after your users have been moved to Office 365 they start complaining that their archive is empty.

It seems that – although this scenario is supported – there are some issues with the provisioning process when you move a user to Office 365 that previously already had an Online Archive: it get’s “wiped”. At least, that’s how it looks like.

At first, I though the data would reappear after a while, so I made sure that I waited long enough. Unfortunately even after a few days, the archives was still empty.

I decided to do some tests, to make sure this wasn’t a standalone case. Perhaps something went wrong during the move. To my surprise, tests confirmed what was going on: although the archive contained items prior to the move, they are now empty.

To explain what happens, let me describe the process I used to reproduce this issue.

This first screenshot show the details of the on-premises mailbox that has a cloud-based archive (EOA) enabled. This archive contains 4 (test) items:

image

Afterwards, I moved the mailbox through the Exchange Management Console using the “New Remote Move Request”-wizard.

Because on-premises only a mailbox exists, you don’t have the option to move an archive (which is normal):
image

The move completed successfully, and after having waited long enough (DirSync etc.). I verified the mailbox’s settings:

image

The interesting part here is that the Archive, although having the same GUID, appears to have been moved to the same database as the mailbox. Before the archive resided in database “EURPRD04DG032-db055” whereas now it’s in “EURPRD04DG030-db041”.

To ascertain myself that this wasn’t causing problems, I decided to do another test. When executing the MoveRequest, I specified to what database the archive should be moved to. I made sure that the target database of the Online Archive was set to the database it was already residing in before moving the mailbox:

New-MoveRequest “Testmivh5” –RemoteHostName “hostname.company.com” –targetdeliverydomain “tenant.mail.onmicrosoft.com” –ArchiveTargetDatabase “EURPRD04DC032-db055” –RemoteCredential (Get-Credential)

Note   this cmdlet was executed from PowerShell connected to Exchange Online.

After the move completed (successfully btw), I – again – waited long enough for DirSync/replication/provisioning to occur. I deliberately didn’t force DirSync to ensure that wasn’t causing any issues either. But alas, none of that helped: the archive was again empty.

A quick look at the object’s attributes revealed that – although a target database parameter was provided – the archive still got moved to the same database as the user:

image

Then, I was thinking that the ‘old’ archive perhaps got disabled and that a new one was created. Although this would be strange since the GUID of the archive remains the same, I thought it was worth a try. Again: no joy! No disconnected mailboxes were to be found.

After all this testing, I had reasons enough to call Microsoft Support. After a few calls back and forth, they recently came back to me confirming that this is a known issue and that they’re currently working on it.

Until today I’m still not sure what the cause of the problem is. I haven’t received any feedback yet either. Of course, I will keep you posted as soon as I find out more!

Temporary workaround

It might sound too obvious, but the workaround is simple: either create both archive and mailbox in the cloud or create the (both!) on-premises first and move them together to the cloud. Both cases work just fine!

Conclusion

Although the last thing you’d want to experience is data-loss, I’m well aware that only a few customers, world-wide, would try this scenario. Nevertheless, it’s an issue that should be addressed quickly.

In our case, we have lost only a single archive worth a few hundred megabytes of emails. I can imagine that losing the wrong kind of emails might be a real big issues for some companies. I haven’t asked, but I’m pretty confident that – even though the emails seem lost – Microsoft can somehow recover the data so that you don’t really “lose” anything. I honestly cannot imagine otherwise.

Does this mean that I discourage using features like EOA? Absolutely not. I still have my hosted archive and I am pretty happy with it. Apart from some inconveniences which I will write about another time, it provides me with everything I need. Furthermore, it allows us to give everyone a relatively large archive without having to bear the costs of additional storage.

Until later!

Blog Exchange Hybrid Exchange Office 365

My first impressions of Office 365

Today, Microsoft announced an entire battery of new products from their range of Office products, including the new Lync, Exchange and Sharepoint Server. Along with these new products, they also announced an upgrade to Office 365 which will now be based on the newer version of the aforementioned products.

Along with the improvements that come along with the newer versions, Office 365 itself seems to have matured as well. Not only does the new UI look clean, but Microsoft seems to have done a pretty good job listening to the feedback from its customers.

One of the things that immediately caught my attention, for example, is the ability to turn on/off downloads for your end-users. Before, you couldn’t do this which left the possibility for your end users to download Office from the portal. A 850MB which – if you’re running low on bandwidth – was not really something you liked:

image

Of course new features in Exchange, Lync and SharePoint will also contribute to a much richer experience. I look forward playing a bit with Office 365 in the upcoming weeks.

Make sure to check back as I will be regularly posting updates on my findings!

Until later!

Screenshot of the new admin portal:

image

Office 365

Disappearing (online) archives after moving your mailbox to Office 365…

Office 365 offers great ways to enhance the functionalities of your on-premises deployment. By running the Hybrid Configuration Wizard (which Steve Goodman explains in this article) you can configure both environments to act as one; allowing you to make use of features such as e.g. Online Archives (EOA).

With Exchange Online Archives, your primary mailbox stays in your on-premises Exchange server, whereas the archive will – as the name might have given away – be hosted in Office 365. If you’re interested in finding out more about Online Archives, I suggest that you take a look at Bharat Suneja’s session at TechEd this year: “Archiving in the cloud with Exchange Online Archiving

The problem

To me, one of the most interesting things about a hybrid deployment is the flexibility it offers. You can put a few mailboxes in Office 365, try them out and move more to the service if you like it.

If you are looking to take that approach, this information might be interesting for you!

Imagine the following: you are trying out Office 365 and decide to use Online Archives to start with. You provision the archives and life is great! After a while you decide you want to use more and you decide to move some mailboxes to Office 365. However, after your users have been moved to Office 365 they start complaining that their archive is empty.

It seems that – although this scenario is supported – there are some issues with the provisioning process when you move a user to Office 365 that previously already had an Online Archive: it get’s “wiped”. At least, that’s how it looks like.

At first, I though the data would reappear after a while, so I made sure that I waited long enough. Unfortunately even after a few days, the archives was still empty.

I decided to do some tests, to make sure this wasn’t a standalone case. Perhaps something went wrong during the move. To my surprise, tests confirmed what was going on: although the archive contained items prior to the move, they are now empty.

To explain what happens, let me describe the process I used to reproduce this issue.

This first screenshot show the details of the on-premises mailbox that has a cloud-based archive (EOA) enabled. This archive contains 4 (test) items:

image

Afterwards, I moved the mailbox through the Exchange Management Console using the “New Remote Move Request”-wizard.

Because on-premises only a mailbox exists, you don’t have the option to move an archive (which is normal):
image

The move completed successfully, and after having waited long enough (DirSync etc.). I verified the mailbox’s settings:

image

The interesting part here is that the Archive, although having the same GUID, appears to have been moved to the same database as the mailbox. Before the archive resided in database “EURPRD04DG032-db055” whereas now it’s in “EURPRD04DG030-db041”.

To ascertain myself that this wasn’t causing problems, I decided to do another test. When executing the MoveRequest, I specified to what database the archive should be moved to. I made sure that the target database of the Online Archive was set to the database it was already residing in before moving the mailbox:
[sourcecode language=”powershell”]New-MoveRequest “Testmivh5” –RemoteHostName “hostname.company.com” –targetdeliverydomain “tenant.mail.onmicrosoft.com” –&lt;strong&gt;ArchiveTargetDatabase &lt;/strong&gt;“EURPRD04DC032-db055” –RemoteCredential Get-Credential)[/sourcecode]

Note   this cmdlet was executed from a remote PowerShell connection to Exchange Online.

After the move completed (successfully btw), I – again – waited long enough for DirSync/replication/provisioning to occur. I deliberately didn’t force DirSync to ensure that wasn’t causing any issues either. But alas, none of that helped: the archive was again empty.

A quick look at the object’s attributes revealed that – although a target database parameter was provided – the archive still got moved to the same database as the user:

image

Then, I was thinking that the ‘old’ archive perhaps got disabled and that a new one was created. Although this would be strange since the GUID of the archive remains the same, I thought it was worth a try. Again: no joy! No disconnected mailboxes were to be found.

After all this testing, I had reasons enough to call Microsoft Support. After a few calls back and forth, they recently came back to me confirming that this is a known issue and that they’re currently working on it.

Until today I’m still not sure what the cause of the problem is. I haven’t received any feedback yet either. Of course, I will keep you posted as soon as I find out more!

Temporary workaround

It might sound too obvious, but the workaround is simple: either create both archive and mailbox in the cloud or create the (both!) on-premises first and move them together to the cloud. Both cases work just fine!

Conclusion

Although the last thing you’d want to experience is data-loss, I’m well aware that only a few customers, world-wide, would try this scenario. Nevertheless, it’s an issue that should be addressed quickly.

In our case, we have lost only a single archive worth a few hundred megabytes of emails. I can imagine that losing the wrong kind of emails might be a real big issues for some companies. I haven’t asked, but I’m pretty confident that – even though the emails seem lost – Microsoft can somehow recover the data so that you don’t really “lose” anything. I honestly cannot imagine otherwise.

Does this mean that I discourage using features like EOA? Absolutely not. I still have my hosted archive and I am pretty happy with it. Apart from some inconveniences which I will write about another time, it provides me with everything I need. Furthermore, it allows us to give everyone a relatively large archive without having to bear the costs of additional storage.

Until later!

Blog Exchange Hybrid Exchange Office 365

Office 365 ADFS Client Access Policy Builder.

Earlier this year, Microsoft released an update to ADFS (RU1) which introduced some new features of which Client Access Policies were one. Client Access Policies allow you to restrict access to Office 365 services based on the location (IP) of your clients.

To find out more, have a look at the following TechNet article:

Unfortunately, configuring these policies is rather difficult and cumbersome, due to the regular expressions it uses. At least that was until recently, when I came across this interesting tool that helps building (complex) Client Access Policies.

The policy builder tool will allow you to graphically design and configure policies in an easy and straightforward manner:

    

To find out more about the tool and to download it, visit the following page:

Until later!

ADFS Hybrid Exchange Office 365