Office 365 Advantages (not found in your typical ads)

I am going to outline some advantages available to current Exchange users that migrate to Office 365.

  • If you have Exchange on premise, it is fairly easy to setup a hybrid environment. This means you can have some users with mailboxes on premise and some mailboxes in Office 365 and your end uses experience seamless communication.
  • Users in the cloud see the same address book as users on premise.
  • Users logon to Office 365 using their email address as their logon name and the SAME password as they do on premise.
  • Hybrid configuration allows mail flow between on premise and cloud users to be seen as internal (SCL = -1) if you understand that.
  • Hybrid allows free/busy lookups between on premise and Office 365 to work when creating a meeting.
  • When mailboxes are moved to the cloud, the Outlook client re-configures itself using the autodiscover service and the same profile is used. This means the Outlook OST file does not need to be rebuilt.
  • Mailbox moves can be ramped up to 99% and held there. When you, the admin clicks “finish migration”, the mailbox move is completed within 10 mins or less and the Outlook client is prompted to restart. This allows you control over when the mailbox is migrated. Very important for those “high touch” end users.
  • Phones experience the same automatic reconfiguration as the Outlook client.

Other advantages in going to Office 365 with the E3 or E4 licenses.

  • 50 GB mailboxes with Unlimited Archive mailboxes.
  • An extremely fast installation of Office 2013 (Word, Excel, Powerpoint, etc) that is branded Office 365. We call this a click to run install.
  • Up to 5 installations per user of this version of Office. The license is tied to the user’s Office 365 credentials, so the end user can install Office at home, and when they are no longer with the company, their license expires. No more handing out CDs with the product key written on it with a sharpie (Hoping their kids won’t get a hold of it.)
  • OneDrive with UNLIMITED storage; OneDrive is built into Windows 8.1 and Windows 10
  • Continuous updates to Office 365 online portal (you may know this as OWA) allowing you to take advantage of the latest features without any effort from you, the administrator.
  • High Availability that would cost way more if you tried to implement on premise.
  • The administrator will never have to worry about backups again.
  • End to end encryption is available without having to install an additional appliance such as ZixGateway or Entrust appliance.
  • Ability to keep all mail with “in place hold” feature for a desired duration (such as 7 years), including deleted mail which does NOT affect the 50 GB mailbox quota.
  • The ability to link URLs (Web addresses) that point to large files stored in your OneDrive rather than using traditional attachments. Can’t attach that 100 megabyte powerpoint or visio document? No problem with OneDrive linking.

I haven’t touched on ALL the advantages, but hopefully this will give you some technical insight to the advantages of migrating to Office 365. In future posts, I will go deeper into these advantages.



Deployment of Certificates to Workstations for Wireless Authentication

There are three things to do…

1. Setup Group Policy to auto enroll workstations and servers with certificates
2. Install Enterprise Certificate Authority
3. Setup NPS to allows devices that have certificates issued by the CA to be allowed to connect.

I like to start with group policy first because when you install the CA, it starts handing out certs immediately.
Go to the Default Domain policy or I guess you could create one for this specifically (but I think that’s silly), and expand
Computer Configuration – Policies – Security Settings – Public Key Policies
Go to the properties of “Certificate Services Client – Auto-Enrollment” and change configuration model to “Enable”, then enable the two check boxes in the image below. The first check box allows certs to be auto renewed, since they are issued with a one year life span. The second check box allows certs to be updated if you should choose to modify the template (rare case).

Next, expand Computer Configuration – Policies – Windows Settings – Security Settings – Public Key Policies – Automatic Certificate Request Settings
From there, right click and create a new Policy, and choose the Computer template. Without this template, I find that certs will get issued automatically to member servers and domain controllers, but not workstations.

Regarding the type of template to use, Computer Template or Domain Controller Template, there is a nice chart listed on technet documentation here  and a mention of templates on technet forums here.
It should look like the image below:

The next process is to install the Certificate Authority. Here is my advice, by default the name of the certificate authority is the first part of your active directory dns domain name followed by your server name. For example, if your domain is, and the server is dc1, then the name of the root certificate and the certificate authority will be contoso-dc1. Because it’s possible to move this to another server later on, I don’t like to tie in the server name with the CA name, so I rename it during the installation process of the CA and call it, following my example, Contoso-EnterpriseRoot-CA. That will be the online name and also the name of the root certificate.

Start server manager, and install the Certificate Authority role. During the installation wizard you will want at a minimum “Certificate Authority” and “Certificate Authority Web Enrollment” services checked.  If you plan on giving non-domain member devices (iPads) certificates, then install the “Network Device Enrollment Service” also. This last role service requires you to setup a “proxy” user account to request certificates on behalf of non domain member devices. I like to create a user called NetDeviceEnrollService or something similar to that and put more info into the description area.

During the installation, you will have an opportunity to rename your CA to what you want.

Once it’s installed, you don’t have to reboot the server or anything. In fact, if you open the local certificate store and look at the Trusted Certificate Authorities section, you should see the certificate listed there.

You should start seeing this on all servers and workstations…. why? Because the default setting in windows is to trust any root CA that is “registered in Active directory”. What you see below is a report from gpresult.exe utility on a member server.

That completes the certificate portion installation.
The next part is configuring the Network Policy Server (NPS) to issue certs.
Configure a wireless policy that uses MS-CHAPv2 in combination with certificates issued by the CA.

ICANN Board Votes to Launch New Generic Top-Level Domains

What does this mean to my active directory installation?
Well if you have installed your active directory domain with an internal dns name of .local, as many of us have, then you will want to purchase this domain when/if a provider (such as or network solutions or godaddy) makes the .local available.
When you create any ssl certificate request and send it off for approval, you MUST own those domains in order to get the cert request approved.
Right now, the .local does not exist on the internet, so the cert company says, yea,  no problem, .local is fake.
This is especially important when purchasing certificates with subject alternate names (SAN), like Exchange and Lync. The certificate has names of the external and internal domain names on it.

I know of a few clients who generically call the domain AD.LOCAL and obviously don’t own that name because it’s not for purchase…. yet.

At some point, GoDaddy or Registar or NetworkSolutions will purchase the .local top level domain and then there will be a rush to purchase your internal domain name.
I wish ICANN would have addressed the .local and consider it internal, like how address is in IP addressing.
Maybe that’s one reason to have the internal domain name match the external domain name…. or at least owning both names.

Exchange 2007 /2010 Certificate install

Exchange 2007 /2010 installs itself with a self signed certificate. This means it gets you going with ssl, but it’s not something you want to run with in production. Why? Well, workstations accessing OWA will complain with a popup box saying it isn’t trusted, and SMTP attempting TLS won’t work because the receiving side (something on the internet) won’t trust it. It’s self signed.

So the first thing we need to do is generate a certificate request. This is generated using Exchange powershell, not IIS. Why? IIS does not have the ability to generate an SSL request with SANs. SANs?, Subject Alternative Names, are other names within the certificate besides the normal name, which is called the CN (Common Name).

Typically, an exchange server needs three names:

The first one is for Outlook 2007/2010 users to autoconfigure the client when they are external to the network. An outlook client will user this address to read an xml file off the server to configure the client to user outlook anywhere (rpc over https) to connect.
The name “autoconfigure” is hardcoded into outlook. The external domain in this case is the domain that the user would use for their email. So if the person’s email was, the name would be

The second one is for Outlook Web Access. I typically use this for the Common Name also. Some companies use “webmail”, some use “mail”, and some use “owa”. I like webmail.

The third is the server’s FQDN with “internaldomain.local” referencing the active directory domain name.  You need this name or outlook clients will complain every time they connect. Why? Because Outlook 2007/2010 use a secure connection to the Exchange server, whereas Outlook 2003 does not.

Now, how to generate the code for this? It’s really simple if you go to this site for Exchange 2007 and this site for Exchange 2010 and fill out the info . Remember to include your common name in the first san field also. It may seem redundant, but it’s not.


In my example, the code for 2007 is this:

New-ExchangeCertificate -GenerateRequest -Path c:\certs\webmail_externaldomain_com.csr -KeySize 2048 -SubjectName "c=US, s=Wisconsin, l=Madison, o=Company, ou=IT," -DomainName,,, servername -PrivateKeyExportable $True

For convenience I make a folder off the C drive called Certs, then i place the above text in a text file called commands-used.txt or something like that. That way I can go back to it.

After you generate the file, c:\certs\webmail_exernaldomain_com.csr, you need to submit it the the certificate authority. I like to use because they have the best price on a 4 name san certificate. BTW, these are also called a “unified communications” certificate.
You will get back another file from that is the other half of this certificate.

Download this file, which will end in .cer to the root of the c: drive. Let’s call it newcert.cer for sake of discussion.

Then use the following powershell command to install the certificate.

For Exchange 2007 type:

Import-ExchangeCertificate -Path C:\newcert.cer

You will see it echo back the thumbprint of the certificate, highlight the thumprint and put it in the clipboard.

For Exchange 2010 type:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certs\your_domain_name.cer -Encoding byte -ReadCount 0)) 

For both version of Exchange, the command to enable the certificate is:

Enable-ExchangeCertificate -Thumbprint xyxxyxyxyxy -Services SMTP, IIS

Where the xyx… is the thumbprint you put in clipboard.

Test it by accessing owa, https://servername.internaldns.local/owa on the server and viewing the certificate in the browser.

You can also test it by performing a telnet to the server’s ip address, port 25 and issue a starttls command.

That’s pretty much it for the cert generation. You can delete the private self generated cert if you want. The biggest problem people run into is the powershell code.