Enable-MailUser errors: “Exchange GUID is mandatory on User mailbox” & “Database is mandatory on User mailbox”

Not long ago I had to prepare an Active Directory to be synced with an Office 365 tenant. The company wanted to have Azure Active Directory Sync installed on premises, and sync all the users (and passwords) to Office 365. The plan was to use several of the Office 365 services, with of course Exchange Online included (it always is, right? ).

Because the company was using Azure Active Directory Sync, part of the preparation of the on premises Active Directory was to install an on premises Exchange 2013 Management Server (see here why should you keep at least one Exchange Management Server on premises when you are using AADSync), and to convert all users that will have a mailbox on Office 365 into mail users on premises, so that they can be manageable from the Exchange tools, and have all Exchange attributes. If you have a Hybrid deployment an Exchange mailbox user on Office 365 should be a Remote Mailbox object on premises, but if that is not the case (and for me it wasn’t) a mail user is enough.

Not let’s go straight to the problem I had and that is mentioned on this article title.

When I tried to enable all the users as mail users, I got the following error for almost all of them:

“Exchange GUID is mandatory on User mailbox”..

“Database is mandatory on User mailbox”..

1

So that got me thinking, and the first thing that came to mind was: What Mailbox? The users I am trying to enable as mail users are not mailboxes.

So I went and checked the users properties on AD, went to the attribute editor and find out that although all the users that I was trying to change were not mailboxes on Exchange, most of them had the msExchHomeServerName attribute populated with the LegacyExchangeDN of the server that was probably hosting their mailbox before it was disabled. Something clearly went wrong on the process of disabling those mailboxes in the past, and I needed to remove those attributes.

When I identified that attribute as the possible cause, the next thing I did was to remove that attribute from a single user, and tried to run the Enable-MailUser Exchange cmdlet only against that user. It worked, that was the attribute causing the issue. By the way I highly recommend that you follow the same approach and don’t go and remove an attribute for hundreds of users without making sure that it is the attribute that is causing you the issue.

One other thing that I need to stress here is that those users from which I removed the msExchHomeServerName attribute were NOT mailboxes on my Exchange on premises. DO NOT remove that attribute from production mailboxes!

Not let me tell you how I automated the process to remove the attribute from all my faulty users.

First I needed to have a CSV file with all the users that had the issue. In my case no user on premises had a mailbox, except my admin user, so all I had to do was take a full list of the users and exclude the admin before using the CSV to delete the attribute. On the Exchange Management Shell I ran:

Get-ADUser –filter * -Properties msExchHomeServerName | where-object {$_.msExchHomeServerName –ne $null} |ft userprincipalname, msExchHomeServerName

2

And to export the result to CSV:

Get-ADUser –filter * -Properties msExchHomeServerName | where-object {$_.msExchHomeServerName –ne $null} |Select-object Userprincipalname, msExchHomeServerName | Export-CSV C:\Scripts\UsersToChange.csv –NoTypeInformation

3

4

And again I can’t stress this enough, if you do have some mailboxes on premises you might want to either filter the CSV you get as an output or put an “-And” on the where-object statement above to exclude the mailboxes using an attribute that the users with problems don’t have (i.e msExchRecipientType)

Not that I had the CSV I needed a script to read from that CSV and delete that attribute on all the users with problems. I found this excellent script on the TechNet Gallery that removes Exchange Attributes using PowerShell. But the script had two problems:

  • It removed more attributes that I wanted/needed to
  • It prompted you to enter the users one by one, and I had hundreds

So I created king of a version 2.0 of the script, but to my own purpose of course, so that the script could read from the CSV and automatically remove the attributes from all the users in it.

See below the part that manners on the script, that you need to copy into a notepad and save as .ps1:

Write-host

Remove Exchange Attributes

—————————-

Remove Exchange 2013 Attributes for a Corrupted Active Directory Account

This Script will use a CSV as baseline

Caution : Mailbox Will Go Disconnected and Exchange Attributes will be Removed” -ForeGround “Cyan”

$AllAccounts = Import-Csv -Path C:\Scripts\UsersToChange.csv

foreach ($Account in $AllAccounts) {

$ADaccount = Get-User $Account.Userprincipalname

$FullDistinguishName = “LDAP://” + $ADaccount.distinguishedName

$AccountEntry = New-Object DirectoryServices.DirectoryEntry $FullDistinguishName

$AccountEntry.PutEx(1, “msExchHomeServerName”, $null)

$AccountEntry.SetInfo()

write-host “Changes made to account” $Account.userprincipalname

}

Make sure you edit the path and the file name of the CSV, and you are ready to run the script.

5

Once it’s done go to the user’s attribute editor on Active Directory and see if the value of the msExchHomeServer attribute is null.

6

And re run the Enable-MailUser Exchange cmdlet for all your users again.

7

Job done! Any questions let me know.

Raise your Exchange Server EWS limits prior to starting your MigrationWiz project

There’s an excellent Microsoft article on TechNet that explains how to configure client-specific message size limits, in Exchange 2013.

There are a lot of good reasons to raise your client limits, as there are also a lot of reasons not to. As long as you’re aware of what your on premises Exchange Server can handle, and you’re not exposing the server to overload or degradation of the service, by raising those limits, than from my perspective, you’re fine doing it.

UPDATE: Michael de Rooij just brought to my attention an excellent script he has, that automates everything described on this post. You can read his article here and download the script here. If for some reason you still want to change it manually, continue reading the steps described below.

On this blog post we are going to change the Exchange Web Services limits. The reason behind it is simple: MigrationWiz leverages the Exchange Web Services to move data to and from your Exchange based systems (on premises or in the cloud), and the default limits on an Exchange 2013 will make the migration of every item over ~35MB fail. The solution to have those items migrated is to increase the EWS limits on your target Exchange Server.

Now let me show you what to do that.

To get the limits raised you need to edit the web.config file on both your Exchange 2013 Client Access and Mailbox Servers. The values you need to edit are:

Serve role Configuration file Keys and default values Size
Client Access %ExchangeInstallPath%FrontEnd\HttpProxy\ews\web.config maxAllowedContentLength=”67108864″ bytes
Mailbox %ExchangeInstallPath%ClientAccess\exchweb\ews\web.config maxAllowedContentLength=”67108864″ bytes
Mailbox %ExchangeInstallPath%ClientAccess\exchweb\ews\web.config 14 instances of maxReceivedMessageSize=”67108864″ bytes

In my case I will raise the limit to 200MB. Go here to convert the 200MB in bytes.

200MB = 209715200 Bytes

Let’s edit the web.config

1

Above you can see the path on the Client Access Server.

2

Search for the value to change on the CAS server, and edit it to match the 200MB.

Do the exact same change on the mailbox web.config file, on your mailbox server, or if you have both CAS and Mailbox on the same server, go to the path: %ExchangeInstallPath%ClientAccess\exchweb\ews\web.config

Once the maxAllowedContentLenght change is made on both web.config files, you need to change 14 instances of the maxReceivedMessageSize value, on the Mailbox Server web.config

3

Go to the Mailbox server web.config file location (also used on the maxAllowedContentLenght change).

4

Search and replace the 14 instances.

Once the changes are made, save the web.config file and do an IISReset from the command prompt.

Note: In the web.config file on Mailbox servers, there are also two instances of the value maxReceivedMessageSize=”1048576″ forUMLegacyMessageEncoderSoap11Element bindings that you don’t need to modify.

Now your on premises Exchange Server will be able to handle much larger files via EWS.

How to configure mail flow coexistence between GApps and O365 using internal relay domains and mail users

Are you planning to move your e-mail system from Google Apps to Office 365? Do you have a large number of users, and therefore migrate the users in stages, and therefore set up mail flow coexistence between the two systems? Keep reading.

On this blog post I am going to guide you through the process of setting up mail flow coexistence, between Google Apps and Office 365.

There are several ways to achieve the mail flow coexistence, from an Office 365 perspective, such as:

  • The Internal relay domain with mail users method
  • The Criteria Based Routing method

This blog article will guide you through the mail flow coexistence configuration, using the internal relay domain method. This method as some pros and cons when compared to others, such as:

Pros:

  • Easy to configure
  • If the processes are well defined it’s also easy to manage as the migration goes along

Cons:

  • Requires more processes during the migration stage
  • Requires more changes post migration
  • When not using Dirsync or AADsync the users on Office 365 need to be created via the Exchange Admin Centre or the Exchange Online PowerShell, which makes the user creation process more complicated.
  • When you enable a mailbox on Office 365, for a user being migrated, all new e-mails coming from other Office 365 users (and external users if you already changed the MX record to Office 365), will not reach the Google Apps mailbox and stay only on the Office 365 mailbox. This makes that the process of migrating the user data has to be managed in batches of users, and done ideally over the weekend.

In my opinion, if you’re using Dirsync this method is an option you should consider.

Now let’s get what matters: the steps for configuring mail flow coexistence between Google Apps and Office 365.

Step 1 – Validate your domain on Office 365:

Of course if you are moving to Office 365, the first thing you need to make sure is that your domain is validated there, and enabled for Exchange Online.

On my scenario, the domain that I am using is myexchlab.com

1

I am not going to give you a step by step guide on the simple tasks, such as adding and validating the domain on Office 365, to keep this blog post focused on the essential, which is to set up the mail flow coexistence.

As you can see above you need to make sure that your domain is added and validated, and that the domain purpose is set to ExchangeOnline.

2

As you can also see above, on my Google Admin Portal, my domain is also validated and working there, as that is my current production environment.

Step 2 – Create and enable your Office 365 users as mail users

Depending on the way you create the users, they can already be mail users on Office 365, i.e. if you are using Dirsync or AADSync to push your users to Office 365, you should have them as mail users on premises, which will also make them mail users on Office 365.

To sum up, there are two ways to create all your users as mail users on Office 365:

  • If you’re using Dirsync enable them as mail users on premises and push them to Office 365
  • If you’re not using Dirsync you need to create all your users via the Exchange Online PowerShell, or the Exchange Admin Centre, directly as mail users. The reason is simple: In Office 365, it’s not supported to enable a user without Exchange attributes (just a regular MSOL user) as a mail user. The only way to give him Exchange attributes is to enable an Exchange Online license and create him a mailbox.

In my case I am not using Dirsync, so I am going to show you how to create all my users as mail users. To do so you can use a script (let me know if you need one), or do it manually via the Exchange Online management Shell.

Connect to the Exchange Online Powershell, and run the following cmdlet:

New-MailUser -Name “GApps1” -Alias Gapps1 -ExternalEmailAddress Gapps1@myexchlab.com -FirstName GApps1 -LastName 1 -MicrosoftOnlineServicesID GApps1@myexchlab.com -Password (ConvertTo-SecureString -String ‘P@ssw0rd’ -AsPlainText -Force)

3

Repeat the step for each user you want to create.

4

Now I have GApps1 and GApps2 created on Office 365, both users also exist and have their productions mailboxes on Google Apps.

5

The users are also Exchange mail users, which is fundamental to have both an up to date Global Address list on Office 365, and to make the mail flow coexistence work.

I know that this way of creating the users might seem a bit manual, but there are two things you need to consider:

  • Most of you will be using Dirsync, which makes the user creation process much simpler.
  • You can script the user creation via the new-mailuser cmdlet and make your live easier.

Step 3 – Configure the routing domain in Office 365

In order to have mail flow coexistence between Google Apps and Office 365, you need to set up a forwarding address in each Google Apps user you move to Office 365. In order for it to work, the forwarding address needs to be from a sub domain of your main email domain. In my case I will use onprem.myexchlab.com which is a subdomain of myexchlab.com.

To properly configure the subdomain you need to:

  • Validate it on Office 365 and configure it for Exchange Online
  • Create an MX record for that subdomain, that points to office 365
  • Make sure that the users have a secondary SMTP address for that subdomain, that you will use as forwarding address on google

To validate the routing domain, go to the domains section on your Office 365 portal and click to add a domain.

As the domain is a subdomain of your main e-mail domain, the validation should be instant.

Skip the steps to add users, and make sure that you choose Exchange as domain purpose, as sown below.

6

The Office 365 wizard will give you an option to add the DNS records (depending on your domain name provider), or you can just copy and paste the DNS records and add them yourself. The only relevant record that needs to be created, is the MX record.

7

Make sure you verify that the MX record is created.

8

Step 4 – Configure Exchange Online for mail flow coexistence

On the Exchange Admin Centre of your Office 365 tenant, you need to do two things:

  • Configure your main domain as internal relay
  • Create a send connector to send e-mail to your Google Apps

To configure your domain as internal relay, log in to your Office 365 tenant, and on the bottom left click on “Admin > Exchange”.

On the Exchange Admin Centre go to “Mail Flow” and click on the “Accepted Domains” tab.

9

Select your main e-mail domain, in my case myexchlab.com, and click edit.

10

Select “Internal Relay” and click save.

Now let’s create the send connector. On the Exchange Admin Centre, select “Mail Flow” and click on the “Connectors” tab.

11

Click on the “+” to add a new connector.

12

When creating the new connector, select from Office 365 and to your organization’s email server.

13

Select a name and keep the existing options selected.

14

Select “Only when email messages are sent to these domains” and click on “+” to add your main email domain.

15

Enter one (or several) of the available Google Apps MX record as a smarthost.

16

You can check the Google Apps MX records by doing an nslookup to your domain.

17

Untick the always use TLS option and click next twice.

18

Finally enter a valid e-mail address from your Google Apps environment, and click validate. Make sure the test succeeds.

Migration steps

Now that you have Office 365 configured for mail flow coexistence, let me give you a quick overview on the migration steps:

Define a migration batch

The first thing you need to do is define a group of users to be migrated. Because there’s no sharing of resources cross platforms (i.e calendars), I highly recommend you approach your migration batches on a per department basis. You might want to export all e-mail addresses of the users being migrated, into a CSV file, in order to use that file to script all the forthcoming tasks.

Activate the user licenses in Office 365

Once you have your group of users defined, you need to activate an Exchange Online license for them on Office 365. Like stated previously you can script that, but for the purposes of this blog post I will just activate the license manually, as the main goal here is to explain how to set up the mail flow coexistence.

19

Go to your Office 365 admin portal, click on “Users > Active Users”, select the user you want to license and add an Exchange Online license.

20

Via the Exchange Admin Centre you will be able to see that, the user is no longer a mail user, and it’s now a mailbox.

Note: As stated before, all e-mail coming from other Office 365 users, or external e-mail if you changed the MX record of your main domain to point to Office 365, will now stay on the GApps1 Office 365 mailbox and not on his Google Apps mailbox.

Migrate your user’s data

Now it’s time to push all the data from Google Apps to the newly created Office 365 mailbox. And how can you do that? Well the answer is simple: Use the best tool in the market. MigrationWiz from BitTitan.

https://www.bittitan.com/products/migrationwiz/about

21

MigrationWiz will move all your emails, calendars and contacts, from Google Apps to Office 365. In addition you can also move your Google Drive and your Google Vault data, with other types of migrations supported by the same tool.

Set up the forwarding address on Google Apps

Now at the same time you start to move the data, you need to set up a forwarding address on the Google Apps accounts you’re migrating. I’ll be blogging soon an explanation on how MigrationWiz automatically sets that up for you, but for now I will again do it manually on my GApps1 user.

Log in to https://admin.google.com

Go to Users and click on the user you want to set up the forwarding. Click on “Account”.

22

On the Email routing section add the forwarding address. Untick the “Change SMTP envelope”, the “Google Apps email” (leave a copy on the source) and the “Inherit routes from <your domain>”.

Important note: do not leave a copy on the source mailbox, or else when moving the data to Office 365 via MigrationWiz, you might get duplicates.

23

Another thing that you need to make sure is that all the users being migrated have a @onprem.myexchlab.com secondary SMTP address.

Connect the users to Office 365

Once all the data is migrated all you have to do is set up your users to connect to Office 365 and start working there.

BitTitan also has a tool to help you automate that process: DeploymentPro

https://www.bittitan.com/products/deploymentpro/about

DeploymentPro will configure Outlook for all your users, and bring all attached PST files and signatures from the old profile (if applicable).

Test mail flow

Now that we’ve covered all the migration steps, it’s time to test mail flow between:

  • GApps1 that was migrated to Office 365
  • GApps2 still in Google Apps

Test message from the Internet to GApps1 (Office 365)

With the MX record still pointing to Google Apps, we will send a test message from the Internet to GApps1, that was already moved to Office 365.

24

25

As you can see the message got delivered to Office 365.

Test message from GApps2 (Google Apps) to GApps1 (Office 365)

Now let’s send a message from a Google Apps user to an Office 365 user.

26

27

And again message delivered to GApps1 Office 365 mailbox.

Test message from GApps1 (Office 365) to GApps2 (Goggle Apps)

Now the most relevant test, the one this blog post is all about: mail flow between Office 365 and Google Apps.

Let’s reply to the GApps2 email.

28

29

And there you go. Working!

Internet mail flow considerations

On this coexistence scenario, there is no centralized outbound mail flow, which in essence means that Office 365 users will email directly to the Internet, and the same of course will happen to Goggle Apps users. Having said that, you need to make sure that your SPF record is up to date, and reflects that scenario. For help setting up your SPF record, go to the Microsoft SPF record wizard page.

Summary

Most of the configurations described above only need to be done once, but on the migration steps section you will want to automate everything. I’ve seen a lot of companies concerned with things like setting up the forwarding address on Google Apps, or scripting the way you enable licenses for users. One of my next blog post will be how MigrationWiz automates the forwarding address configuration, and you can ping me if you need more information about that, or if you need scripts for things like enabling the licenses on Office 365.

As stated on the beginning of this post, there are other methods to configure mail flow coexistence between Google Apps and Office 365, and I will soon be blogging about them so stay tuned.

Script to Bulk create Exchange on premises mailboxes

Building an Exchange lab? Need to create some test users? Well that happens to me a lot, so I decided to build a quick script that basically creates 50 mailboxes on my newly created lab, in less than 5 seconds 🙂

So the script is very simple:

#Run this script from the Exchange Management Shell
#Author: Antonio Vargas
#Declare Variables – Change the Domain and the Database to match your environment
$Number = 1
$domain = “Domain.local”
$Database = “EXCHDB”
#Cycle to create 50 Mailboxes. If you need less than 50 change the “-lt 51”. i.e if you need five change to “-lt 6”
while ($Number -lt 51){
New-Mailbox -UserPrincipalName “User$Number@$domain” -Alias User$Number -Name “User$Number” -firstname “User$Number” -database $database -Password (ConvertTo-SecureString -String P@ssw0rd -AsPlainText -Force)
$Number = $Number + 1
}
write-host “All Test Mailboxes created”

So just copy and paste the above to a notepad, save the file as .ps1, and run it from an Exchange Management Shell of one of your Exchange on premises servers.

The password of each user will be set to”P@ssword” but that of course is also something on can change on the script.

1

And you can say goodbye to having to manually create users each time you need to spin up an Exchange lab! 🙂

As always, any questions let me know.

Office 365 Public Folders Migration: Why and when to use MigrationWiz and not the Microsoft native tool

Migrating legacy Microsoft Exchange Public Folders to Office 365 is a challenge that many Organizations are facing at the moment, and the first question that comes to mind is: “What tool shall I use?”

From my perspective and experience, you have two valid options to push your Public Folders to Exchange Online:

  1. The Microsoft Native tool
  2. MigrationWiz from BitTitan

Reasons to use the MigrationWiz Tool

When the source is a Hosted Exchange

Most of the steps you need to follow on the Microsoft TechNet article, to migrate the legacy public folders to Office 365, require full control on the source system. No Exchange hoster will give you the control and permissions you need to use the Microsoft Native tool, therefore using MigrationWiz will be the best option in this scenario.

When the source is Exchange 2013

Microsoft states the following, on the official technet article:

“Exchange supports moving your public folders to Office 365 and Exchange Online from the following legacy versions of Exchange Server:

  • Exchange 2010 SP3 RU8 or later
  • Exchange 2007 SP3 RU15 or later”

This means that when the source is Exchange 2013, at the moment there is no official and supported migration path to move the public folders to Office 365, as you can also read on the BitTitan’s blog article, that describes the experience of the Microsoft Exchange expert and blogger Todd Nelson.

Because you don´t need to patch your existing Exchange Servers

As described above, and stated by Microsoft, to run the native tool your source servers need to be patched with at least Exchange 2010 SP3 RU8 or Exchange 2007 RU15. Patching Exchange servers might require downtime, and if you´re moving to Office 365, chances are you will decommission all Exchange Servers, keeping only one for management if you are using AADSync. So why schedule a maintenance window and patch servers there are soon to be decommissioned? MigrationWiz supports major versions with no specific requirements on the service pack or update rollup.

Support for large Public folders

MigrationWiz adds great value, when you have large individual public folders, and/or the total amount of public folder data to be migrated is very large.

But let’s start with the individual public folders. Microsoft clearly states the following, on the native migration TechNet article:

“Before migration, if any public folder in your organization is greater than 2 GB, we recommend either deleting content from that folder or splitting it up into multiple public folders. If either of these options isn’t feasible, we recommend that you do not move your public folders to Office 365 and Exchange Online.”

Which means that they do not support the migration of public folders larger than 2GB, or at least if and when you have a problem with your migration (and believe me, chances are you will), related to folders bigger than 2GB, the Microsoft support will probably give you an answer based on the statement above.

By default the Public folders on Office 365 cannot be larger than 2GB, but as you can see on the Public Folder limits Technet article, that limit can be extended up to 10GB. If you have public folders with more than 2GB (and of course less than the 10GB limit), all MigrationWiz requires is that you prepare your target environment, by following this article.

Regarding the large total amount of data to migrate, the great value of the MigrationWiz tool, when compared to the native tool, is the capability of, in case of error, getting more detailed information, and more importantly, not having to restart a migration. I was forced to restart very big migrations, done with the Microsoft Native tool, after getting very vague errors, and because the Resume-PublicFolderMigrationRequest was not working, to get my failed migration back in motion. As you can imagine having to restart a 400GB Public folder migration that was 50% done, it´s not a good experience 🙂

1

As you can see on the example above, the errors on the MigrationWiz portal are very clear and detailed, which helps a lot when troubleshooting. Public Folder mailboxes in Office 365 have a limit of 50GB per mailbox, therefore, if you´re migrating more than 50GB of data you need to follow this MigrationWiz article.

More details and statistics during the migration

Although with the native tool, you can run a Get-PublicFolderMigrationRequestStatistics, with the “-includereport” option, and export it to csv, that is nothing compared to what the MigrationWiz portal provides you.

2

You can see both the total number and size, per item type, with errors or migrated successfully.

3

There’s also information on the data migrated, items migrated or transfer speed, for you to have a better understanding of how things are progressing and estimate total migration times.

4

You can see the migration history, and all kinds of statistics, including a very useful data and item speed per hour statistic.

All the above is, in my opinion and based on my experience, very important when you are migrating a large amount of data.

It´s easy to migrate

The way I see it, unless you have very good technical knowledge of both Exchange online and on-premises, you should go for a tool like MigrationWiz that makes your life much easier.

I’ve seen a lot of issues when using the Microsoft Native tool (and you can find some posts in my blog on how to solve them), and if you don’t have advance knowledge, and you want to use the tool, you should find someone that has that knowledge and experience, and can assist you with the migration.

To be clear:

Is the Microsoft native tool, to migrate public folders, a good tool? Yes!

Does it work? Yes!

Is it challenging from a technical perspective? Yes!

Reasons to use the Microsoft Native Tool

If none of the above is relevant to you or your Organization, and you are an expert on Exchange online and on-premises, then you can use the native tool.

The bottom line is that, everything I stated on this post is based on the large experience that I have with Office 365, and more specifically with migrating Public Folders to Exchange Online. I´ve helped dozens of Organizations to achieve that, and learned a lot in the process.

I hope this post was helpful and as always, let me know if you have questions!

MigrationWiz: Public Folder migration fails to check destination credentials “No Public folder mailbox found” error

Are you trying to migrate your Public Folders to Office 365 and getting the error below?

1

Of course the first thing I recommend is obviously for you to check if you do have Public Folder mailboxes created in your Office 365 tenant. Log into the 365 portal, click to Admin Exchange, and then go to Public Folders > Public Folder Mailboxes.

4

You might need to wait up to 5/10 minutes after you create the Public Folder mailboxes and before running the MigrationWiz Public Folder project.

Also please make sure your MigrationWizAdmin user has the necessary permissions on the Public Folder structure. Read here for guidance.

Now what if everything described above is configured correctly, and you still have the same “No public folder mailbox found” error? Of course all the configurations described above are mandatory, but the real reason for this post is that something else might cause this error.

If all your users were moved to Office 365, and are accessing the Public Folders on premises, before you move those public folders to Office 365, I am sure you followed the Microsoft official article “Configure Legacy on-premises public folders for a Hybrid deployment“.

To enable the access to the legacy public folders, amongst other things, you need to run the following cmdlet:

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3

What the above cmdlet will do is, at the organization level set the Public Folders to remote, and more importantly, by setting the “RemotePublicFolderMailboxes” parameter and the OrganizationConfig level, it will change the “DefaultPublicFolderMailbox” parameter at the mailbox level, for all user mailboxes.

2

Above you can see that the RemotePublicFolderMailboxes is set to a mailbox called admin.vargas, and in your scenario it should be the name of an on premises mailbox, “dirsynced” to Office 365.

3

And if you look at the DefaultPublicFolderMailbox on your users, including the MigrationWiz admin user, that value will be set for the on-premises mailbox setting to match the “RemotePublicFolderMailboxes” parameters on the Organization Config.

So how does this affect the MigrationWiz project? Simple. Looking at the example above, the DefaultPublicFolderMailbox of the migwizadmin user is an on-premises “dirsynced” to 365 mailbox named “Admin.Vargas”, and that causes MigrationWiz to assume that there is no available public folder mailbox on 365. The solution is simple. Run the following cmdlet on your Office 365 Exchange PowerShell:

Set-Mailbox -identity migwizadmin@domain.onmicrosoft.com -DefaultPublicFolderMailbox PFMBX

4

You can see your Public Folder mailbox name, on your Office 365 Exchange Admin Centre, as shown above.

5

The cmdlet and the output, from the Exchange Online PowerShell.

Once the change is made, retry the MigrationWiz project, and job done!

There are a lot of good reasons for you to be in the scenario described above – Using MigrationWiz under a hybrid scenario, to move your public folders to Office 365 – especially if you have Public Folder with more than 2GB and a total amount of Public Folder data of more than 50GB. I will soon blog about all the advantages of skipping the Microsoft native tool to migrate the public folders and using MigrationWiz. Stay tuned!

Yet another Exchange legacy Public Folders replication issue: Old content not replicating to new PF databases

If you´re reading this post, chances are you´re stuck with a public folder replication issue. I´ve seen all sorts of issues with the replication of legacy public folders, but none without solution, so hopefully your solution is here 🙂

My scenario:

  • Exchange 2010 Service Pack 2 in 3 servers (2 existing and 1 new)
  • CAS/HT/Mailbox roles on all servers
  • Each server has a public folder mailbox
  • One server in Asia, one in America and one in the EMEA region

My problem:

The new public folder database was not getting all the existing public folder replicas/content.

Instead of going direct to my issue, let me guide you through all the steps you should take to make sure you understand why your replicas are not being pushed to the new PF database:

Have you added all the replicas (or the ones you need) to your new public folder database?

AddReplicaToPFRecursive.ps1 -Server <ExistingServer> -ServerToAdd <NewServer> -TopPublicFolder “\”

AddReplicaToPFRecursive.ps1 -Server <ExistingServer> -ServerToAdd <NewServer> -TopPublicFolder “\NON_IPM_SUBTREE”

The script above is on the Exchange scripts folder, and can be ran from an Exchange Management Shell. Look here for more details on the script.

You can check which replicas a public folder has, by running:

GetPublicFolder -Identity ‘\’ –Recurse | fl Name, Replicas

Get-PublicFolder -Server <NewServer> -Recurse

Is the above done and your public folder database is still not up to date?

If you do have the replicas pushed to the new server, and the content is still not being replicated, then please also check if the mail flow between the source and destination server is working.

In my case of course it was working, because as stated on the title of this post, only the old content of the public folders was not being replicated. New content was fine, which means that issues like mail flow or invalid replicas were ruled out.

An example:

UserA was connecting to a database on the new server that was using the new public folder database. Via OWA UserA opened the Public Folders, and created a new item. The item was replicated to all the Public Folder databases on all servers. UserA can only see a very limited number of items on the Public folders, all recent and created after the creation of the new PF Database.

So lets take a closer look at the statistics of a specific folder:

pferror1

The Public Folder “US” had zero items in the new server and 1087 on the old one. An item created now would replicate to both the new and the old server, but nothing was happening to old content.

Now before I continue, it´s mandatory for me to recommend you read an excellent Public Folder Troubleshooting article from the Ehlo Blog.

The next step is to raise the event log level on both the new and the old server. The logs you need to set to expert are under the “MSExchangeIS > 9001 Public” and are named “Replication Incoming Messages” and “Replication Outgoing Messages”.

pferror2

Now let’s force an update on a public folder by running on the new server Exchange Management Shell:

Update-PublicFolder -identity “\US” -server <OldServer>

And on the new server event viewer you can see the 0x20 Status Request event (see the troubleshooting guide provided above for more info on event codes).

pferror3

On the old server you can see the status request reply:

pferror4

But what you never see is an event like the one below, with status 0x4 that indicates that content is being replicated.

pferror5

So what is the solution? Update all the content using the ExFolders tool.

Click here to download it, and for full instructions on how to run it.

Once you have the Exfolders opened and connected to the old server, select the folders you want to update (in my case I selected the route because I wanted to update all) and click on “Modify All Items”.

pferror6

IMPORTANT NOTE: This will cause a replication storm, which means that all public folders on all databases will be updated and replicated. If you have a large public folder infrastructure you might want to consider doing this procedure during off work hours.

You will then see the folders being updated.

pferror7

And once that is done, wait for the replication to take place and run the public folder statistics cmdlet again.

pferror8

All up to date!

Hope that the above was helpful..

Set-AzureStaticVNetIP Error: The static address doesn’t belong to the address space defined by the role´s subnet

Quick blog post on a simple and logic error that you might get when you´re trying to set a static IP on your Microsoft Azure VM.

1

So as you can see above, when you try and run:

Get-AzureVM -ServiceName MYMSEXCHANGE -Name TestVNetVM |Set-AzureStaticVNetIP -IPAddress 192.168.0.150 |Update-AzureVM

You get the error:

“Update-AzureVM : BadRequest : The static address 192.168.0.150 doesn’t belong to the address space defined by the role’s subnets.”

The reason behind this error is simple: You are trying to set a static IP for your VM that does not belong to the subnet where the VM is. So let’s have a quick look on how to see which subnet does your VM belongs to. From the azure PowerShell run:

$MyVM = Get-AzureVM -ServiceName MYMSEXCHANGE -Name TestVNetVM

Get-AzureSubnet -VM $MyVM

2

The output will show you the Subnet of your VM.

You can also see the network where your VM is on by running:

Get-AzureVM |fl Name, VirtualNetworkName

4

Now that you know what network and subnet your VM is on, you can go to the Azure Portal > Networks, and on the Configure tab of the network you can see the range of IP addresses from the subnet of your VM:

3

In my case the VM is on the subnet-2, with a range of Ip’s of 192.168.1.0/24 and i was trying to set up an IP address on the 192.168.0.0/24 range.

Let’s try with a valid IP now on the 192.168.1.0/24 network:

5

No error, job done, and as simple as it gets! 🙂

Microsoft Azure Tip: How to assign a static IP address to your Azure VM

This blog post will quickly show you how you can assign a static IP address to one of yours Microsoft Azure Virtual Machines, using the Microsoft Azure Powershell.

Assuming that you have already created at least one virtual machine, on your Azure subscription, the first thing you need to know and do is, how to install and configure the Azure Powershell.

On the article from the above link, you can follow the instructions to install the Microsoft Azure Powershell and to connect it to your Azure subscription.

Now let’s login to the Microsoft Azure Management Portal, and start by looking at the Virtual Networks.

Network-VM-1

I created a virtual network on my subscription, named “vlan192”, and as you can see the virtual machine “DC01” got the IP address 192.168.0.4 assigned, which is part of a sub. Now I will change that IP address to one of my choosing.

Network-Subnets-2

Above you can see the virtual network in more detail. Before assigning a static IP address to your virtual machine, make sure the address you choose is within the usable address range of one of the subnets of your virtual network. My virtual network has two subnets.

One other thing that you need to take into account, is that when you create the Vitual Machine, you need to make sure that you assign the correct virtual network and subnet to it, as shown below:

Network-createVM-3

You can always go to the Dashboard of the virtual network, and make sure that the Virtual Machine you created is listed there, and what subnet is the virtual machine using.

We can now connect to the Microsoft Azure Powershell and set the static IP. Let’s start by running the following cmdlet to see the details of the existing virtual machines:

Get-AzureVM

The cmdlet above will give you the servicename and the virtual machine name that you need to run the cmdlet that sets the static IP:

Get-AzureVM -ServiceName <ServiceName> -Name <VMName>  | Set-AzureStaticVNetIP -IPAddress <StaticIP> | Update-AzureVM

Below you can see the output of the cmdlet.

Network-changeIP-4

And finally if you go to the properties of the virtual machine, on the Azure Management Portal, you can see that the static IP is set.

Network-checkIP-5

IMPORTANT NOTE:

You need to be aware is that the IP above is assigned to the specific VM. A reservation is made and therefore that will be the IP of the virtual machine as long as the reservation is kept. This does not change the network properties at the OS level. It doesn´t set the static IP there. You should now login to the virtual machine and set the static IP to match the reservation, as you are now sure that it won’t cause any IP address conflict.

Office 365 tips: Automatic DNS records creation when your custom domain is hosted with GoDaddy

Last week I started another Office 365 project. The custom domain to validate is hosted with GoDaddy, so once more I took advantage of the excellent integration feature between Office 365 and GoDaddy.

This feature is not new, but it’s very good and therefore always worth blogging about it.

Click here to see the official statement from Microsoft, about this integration, and a demo video.

Now a quick walkthrough. My domain was already validated, but you can use the integration also for the domain validation, as it creates the necessary DNS record.

After the domain is validated and you set the domain purpose, the Office 365 Admin portal detects that your domain provider is 365, and you can then click on “Add Records” to add your DNS records.

1

Before adding them, you can see the detail by expanding “View the DNS records we’ll add”.

2

A GoDaddy logon window will pop up. Enter your username and password.

3

Click confirm to accept the changes on your public DNS zone.

(Note: Apologies about the Portuguese screenshoots)

4

You will then get the confirmation that the changes were done.

5

And if you login to your GoDaddy account and edit the zone file for your domain, you will see all the new DNS records there.

6

That’s it. As simples as that! Enjoy!