There are few really good articles on Office 365 and PowerShell. I recently had a pleasure to provision and configure one Office 365 instance for one of my clients and to be honest, few of those articles pointed me in the right direction but didn’t give me all required information I needed. It is impossible to write a uberarticle and I am definitely not trying to do that here. However, I found few interesting things I would like to share with you. Also, being a lazy guy from time to time, I want to leave few notes to myself for the future. I will definitely need this stuff again 🙂

At the first, I thought everything will fit into one blog article. However, as more I wrote I was more aware of the fact that this is becoming an monster article. Maybe I am only getting this impression from the amount of text and screenshots I have currently in my OneNote. On the other side, I was never fond of reading huge amounts of text in an single shot so I decided to split the article into (currently) two parts:

Creating an Office 365 instance

To create an Office 365 instance, go to http://www.microsoft.com/en-us/office365/compare-plans.aspx and select your plan. For purposes of this article, I selected Midsize Business & Enterprise option (E3 plan) as a free 30-days trial.

In order to create your Office 365 instance you will need to fill in the form presented after you selected your plan. The form itself is pretty self-explanatory. It is important to enter proper information in all fields; however, the one you don’t want to mess with is Country or region. Based on your selection, the provisioning process will select an appropriate data center for hosting your data. Unless you don’t want your data hosted half way around the globe (and experience nice little thing called latency and possibly some legal issues depending on country you are living in), be very careful with what you select here. This option can’t be changed after sign up.

By clicking I accept and continue button, you will accept terms of use and start provisioning process. You will get in to Office 365 administration quite quick; however, it can take up to 15 minutes for all services to be provisioned.

Connecting to Office 365 instance with PowerShell

As an administrator, you can use Windows PowerShell to perform various administration tasks on your Office 365 instance. This is achieved using a wide set of Office 365 cmdlets. To begin using Office 365 cmdlets, you need to install them first. The requirements for installing the Office 365 cmdlets are as follows:

• You must have at least Windows 7 or Windows Server 2008 R2 running
• You must have Windows PowerShell and the .NET Framework 3.5.1 enabled
• You must install the Microsoft Online Services Sign-in Assistant. Download and install one of the following from the Microsoft Download Center:
  • Microsoft Online Services Sign-In Assistant (IDCRL7) – 32 bit version
  • Microsoft Online Services Sign-In Assistant (IDCRL7) – 64 bit version

If your environment have met the requirements, download and install one of the following from the Microsoft Download Center:

• Microsoft Online Services Module for Windows PowerShell (32-bit version)
• Microsoft Online Services Module for Windows PowerShell (64-bit version)

After you have completed the installation of the Microsoft Online Services Module for Windows PowerShell, start PowerShell and import the module:

Import-Module MSOnline

Now you have an access to all Microsoft Online Services cmdlets. To start administering your instance, you have to use Connect-MsolService cmdlet. To determine to which instance the connection will be made, this cmdlet requires administrator credentials passed as a parameter (also, not to forget, to authenticate the user :)). Let’s grab credentials and connect to the service.

$cred = Get-Credential
Connect-MsolService -Credential $cred

Now that you established a connection to your Office 365 instance, you can start with…

Adding and verifying domains

The next step is to add and verify the domain. The domain I am going to use is already purchased so I am not going to describe this procedure here (anyway, it is out of scope of this article). If you do not have an registered domain, it would be a good time to get one at your domain registrar.

To add a domain, run the following Windows PowerShell cmdlet:

New-MsolDomain -Name adr-it.de

To get the list of the domains associated with your Office 365 instance, run the following Windows PowerShell cmdlet:

Get-MsolDomain

This cmdlet will give us a collection of Microsoft.Online.Administration.Domain objects. The console output will look something like this:

Name                               Status          Authentication
----                               ------          --------------
adrittest.onmicrosoft.com          Verified        Managed
adr-it.de                          Unverified      Managed

Now, note the Status property and values for both domains. Domain adrittest.onmicrosoft.com is already verified as it is been provisioned by Office 365. Domain adr-it.de is not yet verified as we added it manually. Why verification? Imagine that we add something like microsoft.com in here. Now, it is obvious that we do not own microsoft.com domain so there is the reason why Office 365 requires verification. You can safely add to that dozens of possible issues you could run into if it would be possible to register one domain with multiple Office 365 instances. Luckily, Office 365 prevents this.

Now, there are few options to verify domains. As mentioned earlier, as soon as you add domain to your instance, Office 365 is going to generate verification codes. Verification codes are actually in form of DNS entries so you need to add them to your domain. You can use MX or TXT records. TXT records are recommended because they won’t influence your current services in any way. MX records, configured improperly, definitely can.

So, where are our verification codes? There is a Windows PowerShell cmdlet for this purpose as well. Run following:

Get-MsolDomainVerificationDns -DomainName adr-it.de -Mode DnsTxtRecord

You will get an output similiar to this one:

Label : adr-it.de
Text  : MS=ms10728978
Ttl   : 3600

This means that we need to create a TXT record for domain adr-it.de containing MS=ms10728978 and time-to-live of 1 hour. For example, if you use BIND as your domain name server, you would add following in the configuration for the adr-it.de domain:

@  3600 IN TXT “MS=ms10728978”

Here is an example how the configuration looks like at my domain name registrar:

Some DNS providers however do not allow creation of TXT records. This is where you can use MX records for verification. To get MX verification codes for your domain, run the following Windows PowerShell cmdlet:

Get-MsolDomainVerificationDns -DomainName adr-it.de -Mode DnsMXRecord

You will get an output similar to this one:

Label        : adr-it.de
MailExchange : ms10728978.msv1.invalid
Preference   : 32767
Ttl          : 3600

To be able to continue with the verification, we will need to create an MX record for domain adr-it.de pointing to ms10728978.msv1.invalid.outlook.com with preference 32767 and time-to-live from 1 hour. It is very important to set preference to 32767 in order to ensure that current mail transport is not affected by this dummy record. To get back to our BIND configuration, you need to add following line to the configuration of adr-it.de domain:

@  3600 IN MX 32767 ms10728978.msv1.invalid.outlook.com.

Again, here is an example how the configuration looks like at my domain name registrer. Note that due to the limitation of the web interface I couldn’t set preference to 32767. However, any priority lower than priority of your active MX records (higher value = lower priority) will do the job.

Now that we have our records created (and propagated), we can continue verifying domain. To complete domain verification, run following Windows PowerShell cmdlet:

Confirm-MsolDomain -DomainName adr-it.de

By running this cmdlet, you will trigger Office 365 to check for created DNS records. Once Office 365 finds required DNS records it will complete the domain verification process by marking the domain as verified. You can run Get-MsolDomain cmdlet to check this:

Name                               Status          Authentication
----                               ------          --------------
adrittest.onmicrosoft.com          Verified        Managed
adr-it.de                          Verified        Managed

Assign domains to Exchange Online and Lync Online

Initially, I thought there wouldn’t be much to say about assigning domains to services. It was actually supposed to be done with only one call to Windows PowerShell cmdlet Set-MsolDomain. Well, guess what – it isn’t so simple. Actually, in current implementation of MSOnline module, there is no way to do this with PowerShell. Why? Well, seems that somebody simply forgot to add the parameter and implement appropriate code. Now, why bother at all? First of all, this article is about configuring Office 365 with PowerShell (yay!). Second thing, imagine you have to assign 50-100 domains to your Office 365 instance. Clicking through Office 365 Admin interface to accomplish this is really not my idea of having a good time.

Nevertheless, there is no way around it. Go to https://portal.microsoftonline.com, log in with your admin account and once you are in the Office 365 administration, click “Domains” link on the left side.

Now, click on domain name (in this case, adr-it.de). This will open an page with information about the selected domain. Also, you have an option to change service assignment here:

Now click the Edit domain intent button to open Change domain services dialog. Select Exchange Online and Lync Online and click the Save button. Please note that you can assign domain to either Exchange and Lync Online or SharePoint Online. You cannot assign an domain to all services. We will deal with this later.

Adding and assigning SharePoint Online domain

By provisioning a Office 365 Enterprise instance three subdomains will be automatically registered with SharePoint Online. Also, three site collections are automatically provisioned:

• Team Site: https://adr-it.sharepoint.com
• Search center: https://adr-it.sharepoint.com/search

• MySite: https://adr-it-my.sharepoint.com

If we want to create our public home page using Office 365 we will definitely want to use our own domain. It is rather uncommon for your homepage URL to be in the form of adr-it-web.sharepoint.com. It is not representative and it is complicated to remember it. Good news is, we have an option to change this.

So, lets add the new “domain” for SharePoint Online. Actually it is not a domain itself nor a subdomain, it is simply a DNS entry which needs to be registered with Office 365 so that we can use it. We can achieve this by running following  Windows PowerShell cmdlet:

New-MsolDomain -Name http://www.adr-it.de

This cmdlet will register www.adr-it.de with Office 365. Let’s take a look at the cmdlet output:

Name                               Status          Authentication
----                               ------          --------------
www.adr-it.de                      Verified        Managed

Note the Status property and its value. From Office 365 perspective this domain is already verified. Why? Well, although we didn’t got any verification codes and we didn’t run Confirm-MsolDomain cmdlet, we did this for the parent domain (in our case adr-it.de) meaning we already proved we own the domain.

Now that we added the subdomain, we need to assign it to SharePoint Online service. Unfortunately, we can’t achieve this with PowerShell, as earlier described. To complete this task we will have to go to the Office 365 administration one more time.

Now, navigate to https://portal.microsoftonline.com, log in with your admin account and once you are in the Office 365 Admin interface, click the “Domains” link on the left side.

Click on the domain name (in this case, www.adr-it.de). This will open an page with information about the selected domain.

Now click the Edit domain intent button to open Change domain services dialog. Select SharePoint Online and click Save.

We just registered the new SharePoint Online domain. To use it, we will need to go to the Admin Overview page in Office 365 Administration, click Manage link for SharePoint in the Microsoft Office 365 group and click Manage Site Collections link.

Configuring DNS records

At this stage, Office 365 is fully configured for use with your domain. The only thing missing is to tell clients where to connect and this is done by adding and configuring an couple of DNS entries.