Wednesday, August 28, 2013

Windows Server 2012 - installation, GUI to Server Core to GUI

Windows Server 2012 - Installation features


After a good number of posts on Exchange 2010, I'm going to take a look at Windows Server 2012. This is a new server OS that system administrators will have to learn and Exchange administrators in particular, at least if they want to become certified in Exchange 2013. Passing Microsoft exams 70-410, 70-411 and 70-412 is a pre-requisite for certification in Exchange 2013. 
I'll start with the installation then. This first post will cover the basics of a Full (GUI) installation which is essentially a matter of following the prompts.
So, to make the post a little more interesting, I'll explore one of the new Windows 2012 features that allows the admin to convert a Full installation into a Server Core installation and vice versa.

Full installation

I'm working in a virtual environment (VMware workstation 9) and I'll boot from an .iso image:

First, we have to select the language and regional settings - we'll go with the defaults:

Click on "Install now" (and "Next" as necessary - very simple "follow the prompts").
We then have a combination of choices: Datacenter or Standard and Server Core or Full (GUI) installation. I'll opt for the Full installation and then demonstrate later how we can move from one to another.

Some notes:

As was already the case for Windows Server 2008 R2, there is no 32 bit version of Windows Server 2012, so no choice is neceessary there.

In fact, there are 4 editions of Windows 2012 (all 64 bit):

  • Datacenter. This version (OEM only) comes with unlimited licensing for virtual machine clients and offers features such as the ability to add hardware without turning the machine off.
  • Standard. This version has the same "native" features as Datacenter but with only 2 licenses for virtual clients and without the special OEM hardware associated with Datacenter.
  • Essentials. This version has most of the features of the Standard edition except for Server Core, Hyper-V and Active Directory Federation Services. It is also limited to 25 users.
  • Foundation. Limited to 15 users, this edition is for customers requiring only very basic services, such as file and print services.
All editions may not be included on the same media however, hence the absence of Essentials and Foundation in the screenshot above.
On the next screen (not shown), we accept the license agreement (if we want to continue the installation) and on the screen after that, we select the second option (custom) since this is a new (fresh) installation:

We'll install Windows 2012 on a small 36 GB partition which would not be enough for a production environment but more than enough to examine the various install options:

Note: minimal hardware requirements for Windows 2012 are of little concern since it would be difficult to find servers with such limited resources today:

  •  Processor: 1.4 Ghz (64 bit only)
  • RAM: 512 MB (maximum = 4 TB)
  • Disk space: 32 GB

When the installation process completes, the server will reboot and we'll be prompted to enter a password and then press Ctrl-Alt-Del to logon.

As with Windows 2008, the Server Manager (Dashboard) interface displays once the admin logs on (although the format of the interface is quite different from W2K8).

Let's click on "Configure this Local Server"

The elements that can be configured are shown.

We'll configure the server name and IP address. We can add the server to a domain later as needed.

First the name change:

We need to restart for changes to take effect but we'll restart after we configure the IP address.

Note that the NIC is now called "Ethernet" instead of "Local Area Connection".

We'll right click on the icon, select properties and then open the IPv4 properties.

Configure the IP settings as appropriate for your environment (what follows is a simple example):

To restart, I'll open Powershell and type shutdown /r (there is no start button to restart the server):

Conversion to Server Core

Now that the full (GUI) installation is complete, we can convert the installation to Server Core.

In the upper right-hand corner of Server Manager, click on "Manage" and then select "Remove Roles and Features":

Select a server from the server pool, in this case SVR-1 (the only one):

Skip the "Roles" section and proceed to the "Features" page. Uncheck "Graphical Management Tools and Infrastructure" and "Server Graphical Shell":

Remove dependent features as needed:

Confirm the operations and click on Remove (button in lower right-hand corner, not shown in screenshot):

If you did not check the "restart" box (in screenshot above), you have to restart the server manually after the the features have been removed:

Server Core

When the server restarts, we are in "Server Core". There is nothing but a command prompt:

We can configure just about everything at the command line - if we know the commands. Many (most) administrators will prefer to manage the server remotely using Server Manager. Even so, it is useful to know how to complete some basic operations at the command line.

We can see the server's name and IP address with the following commands:

- hostname
- ipconfig

We can even change these settings at the command line:

Computer Name

netdom renamecomputer SVR-1 /newname:SVR-CORE-1

Confirm the operation when prompted and restart the server.

IP address

We can change the IP address of the various network interfaces.

To see the interfaces (without ncpa.cpl), enter this command:

netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 12          10        1500       connected     Ethernet

To configure a static IP address, enter this command (adjust as appropriate for your network):

netsh interface ipv4 set address Ethernet static


Windows IP Configuration

Ethernet adapter Ethernet:
   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::81d[...]
   IPv4 Address. . . . . . . . . . . :
   Subnet Mask . . . . . . . . . . . :
   Default Gateway . . . . . . . . . :

Conversion to GUI

If we manage the server remotely, from a workstation, using Server Manager (or even Remote Powershell), the Server Core interface will not be a problem.

Even so,  some admins may prefer the GUI.

So how do we convert the Core interface to the GUI?

In theory, we should be able to enter the cmd "sconfig" and select the option to "Restore Graphical User Interface (GUI)"

However, for some reason, this option is missing:

Let's use DISM instead.

What is the state of the feature (one example)?

C:\>dism /online /Get-featureInfo /featurename:Server-Gui-Shell
State : Disabled

How do we restore the features?

C:\>dism /online /enable-feature /featurename:Server-Gui-Shell /featurename:Server-Gui-Mgmt /featurename:ServerCore-FullServer

(Restart required).

I'll spare the reader a duplicate screenshot and simply state that the GUI will look just like it did above when it was first installed initially.

Final notes

For those that like Powershell, even with the GUI, Powershell can be used to change installation types.

I did encounter some problems however.

Conversion from GUI to Server Core

I try these two commands but the result is the same: an apparent success but in reality a failure: the operation completes in a couple seconds but only in appearance. The GUI is still present after reboot.

PS C:\> Remove-WindowsFeature Server-Gui-Shell,Server-Gui-Mgmt

PS C:\> Uninstall-WindowsFeature Server-Gui-Shell,Server-Gui-Mgmt-Infra

Success Restart Needed Exit Code      Feature Result
-------    --------------               ---------       --------------
True        No            NoChangeNeeded {}

Let's try just one...
PS C:\> Uninstall-WindowsFeature Server-Gui-Mgmt-Infra
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             NoChangeNeeded {}

No, it does not work.

This does work but removes the features entirely:

PS C:\> Uninstall-WindowsFeature Server-Gui-Shell,Server-Gui-Mgmt-Infra -Remove

We need a Internet connection (or other source) to replace them.

Conversion from Server Core to GUI

PS C:\> Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    Yes            SuccessRest... {Graphical Management Tools and Infras...


Monday, August 26, 2013

Exchange 2007 (SP3) - migration (staged) - Exchange Online (Office 365) - Part 8 - DNS

DNS settings for Exchange Online

At this point in the migration, mail is still directed to the onsite Exchange server because the MX records still direct mail to a domain name associated itself with the IP address of the mail server (or the external interface of the organization firewall, for example).

Therefore, as one of the final steps of the migration process, we need to adjust or create the following records, as presented in the domains section of the Office 365 portal.
First, go the the domains section and select the domain for which you want to manage the DNS records.

Click on "View DNS settings". The screen below displays:
These are the DNS records that must be created or adjusted in the web interface of your DNS provider. Directions for some major providers are available. Otherwise, please consult the documentation of your provider.
In my case, I had to do the following:
  • Change the A record for autodiscover - pointing to the external IP address of my firewall - to a CNAME record - pointing to Note: yes, if you select what was an A record, you can click on a radio button for A or CNAME.
  •  Adjust the MX record so it no longer points to but rather the target shown in the illustration above.
  • Create a SPF record (values indicated above).
The results were excellent. Within 30 minutes I could send and receive messages (tested with both Outlook and OWA).
I turned off the onsite Exchange 2007 server so there was no possibility that things were only working because it was still available (since it was not).
This series of posts on (staged) migration to Office 365 has been long but yet incomplete. There are many other subjects that could be examined, notably migrating public folders and accessing email via ActiveSync.
However, I want to avoid limiting myself to a single subject. After having composed many posts about Exchange and migration to Exchange Online in particular, I'm going to change subjects (finally) and take a look at Microsoft's latest server OS, Windows Server 2012 (with R2 recently released).
I would invite those seeking more information about the subjects examined in my posts, and those not examined, to consult the literature published by Microsoft online.

Saturday, August 24, 2013

Exchange 2007 (SP3) - migration (staged) - Exchange Online (Office 365) - Part 7 - Outlook client configuration

Outlook - preparation for use with Exchange Online

As we can see, a (staged) migration from Exchange 2007 to Office 365 (Exchange Online) can be a rather long and complex process.

So let's review once again what we have done so far:
  • Synchronized user, group and contact objects between onsite Active Directory and Windows Azure Active Directory with the DirSync tool (and after enabling the DirSync function in Office 365).
  • Migrated certain mailboxes to Exchange Online.
  • Assigned a license to the users in question.

At this point, I have tested the ability of these users to access their email - as well as their ability to send and receive email. Here are the results:

  • Send and receive to/from other users in the organization (onsite or "online") - OK
  •  Send and receive to/from other users outside the organization (Gmail, Hotmail, Yahoo Mail accounts) - OK
  • Access email with OWA - OK
  • Access email with Outlook - FAIL
So how can we correct this last point?
First, we have to download and install the "Office 365 desktop setup" software.

Once logged on to Office 365, it can be downloaded here...


Or here... (after clicking on the "gear" icon in the upper right hand corner, next to your user name):

Click on the link and proceed to the following page:

As it explains, the desktop setup tool prepares your copy of Office 2007 or 2010 so it can work with Office 365 (Exchange Online).

Note the "Review system requirements" link. Windows 7 and 8 with Internet Explorer 8, 9 or 10 and Office 2010 SP1 (SP2 recommended) are supported in particular. The link provides a complete and updated list.

When you click on "set up", the following application appears and requests your permission to execute:

You are requested to login (again) to Office 365:

The install program checks your system configuration. I performed this operation on a Windows 7 SP1 workstation with Office 2010 SP2, which was apparently satisfactory.

The setup program then summarizes the changes it will make:

If prompted for administrator credentials (UAC prompt), enter those credentials.

Review and accept the service agreements.

(No illustrations)

The Desktop Setup programs installs the components:

Restart the computer to complete installation:

Any luck?

No, the most recent messages recieved appear in OWA but not in Outlook.

Moreover, the Outlook autoconfiguration test shows that the Outlook client is still connecting to the onsite server.

So something is still not right.

Here is the procedure that allows users to access their Exchange Online.

We need to:

  • Disable the user mailbox.
  • Enable the user as a "mail-user"
  • Verify the proxyAddress and targetAddress fields (optional, they may very well be correct from the start).
  • Create a new Outlook profile.

That's a simple summary. The details follow.

Note: I will convert the user mailbox object into a mail user object manually. Microsoft does provide a script that automates the process.
At the time I composed this blog post, the script could be downloaded here:
I could also access the link by performing a search for "office 365 wiki 845".

1. Disable the user mailbox (on the onsite Exchange server).


Confirm the operation if prompted to do so (enter "y" for yes and press enter).

2.Enable  "Alan Reid" (example) as a mail user

Enable-MailUser "Alan Reid" -ExternalEmailAddress

Use the "long" Microsoft online email address here.
Note: the EMC can be used instead of the EMS to disable the mailbox and enable the mail user.

3. Verify settings in user properties - Attribute Editor tab (optional).

- proxyAddress

- targetAddress

The primary SMTP address should be as illustrated above:

4. Create a new Outlook profile (Outlook 2010 in this example)

4.a - Go to: Control Panel | User Accounts | Mail

Note: this is with a Windows 7 client.

4.b - Open "Mail" and click on "Add" (as in add a new profile).

We'll just name our profile "o365".

4.c - Enter the Microsoft online email account information (if it is not entered automatically):

4.d - Grant permission to Office 365 to configure the profile:

4.e - Enter your Office 365 credentials:

Note: in this case, you simply enter your UPN and not the "long" Microsoft address (

4.f - Verify that setup completes successfully.

Now the user can open Outlook and access their email stored in Exchange Online (Office 365)

Unless we implement Active Directory Federation Services (ADFS), the user will be prompted for their pasword each time they open Outlook. We can limit the number of prompts for credentials by checking the "Remember my credentials" box.

The user will be asked for their name the first time they open Outlook - just as they would normally with Exchange located onsite:

In my scenario, the user was able to send and receive messages from his Exchange Online account.

That would be a sufficient indication that the changes have been successful.

Otherwise, we can verify that Outlook is connecting to Exchange Online mail servers, rather than the onsite mail server(s), with the autoconfiguration test.

With Outlook open, locate the Outlook icon (in the lower right-hand corner, on the taksbar but possibly hidden) and after pressing the "Ctrl" key, right-click on the Outlook icon.

Click on either "Connection Status" or "Test E-mail AutoConfiguration":

"Connection Status" should show connections with Office 365:

The email autoconfiguration test should also display results indicating that Outlook is connected to Exchange Online servers rather than onsite servers:

Note: when performing the test, use Autodiscover only. Uncheck the Guesssmart options which are not necessary here.

At this point, the users in question can access their email from either Outlook or OWA.
ActiveSync connectivity is another aspect to consider but that I will not examine in this set of blog posts.
Besides that, one more step remains...
Until now, we have left DNS records related to Exchange (A and MX records) in their existing state. In other words, they still point to the onsite mail server for SMTP traffic (incoming email) and client access.
In the next blog post, we will adjust these records so traffic is directed straight to Exchange Online, which will allow us to decommission our onsite Exchange 2007 server.

Saturday, August 17, 2013

Exchange 2007 (SP3) - migration (staged) - Exchange Online (Office 365) - Part 6.1 - mail flow problems

Post-migration mail flow troubleshooting

After initiating directory synchronization in parts 4.1 and 4.2, migrating mailboxes in part 5, and licensing users in part 6, I tested mail flow between various endpoints.
These were the results.
  • Users not yet migrated could send email to each other (no surprises here).
  • Migrated users (Office 365 users) could send email to each other.
  • Migrated users could send email to external recipients (Gmail,, others).
  1. Migrated users (Office 365 users) could not send email to users not yet migrated (whose mailbox was still onsite).
  2. Users not yet migrated could not send email to migrated Office 365 users.
  3. External senders (using Gmail, could not send email to the migrated Office 365 users.
Problem 1
 Problem 1 was caused by the filtered synchronization for which we opted in part 4.x.
Only users, contacts and groups in the following containers were synchronized with Windows Azure Active Directory:

Therefore, Windows Azure Active Directory had no reference to those users and cannot resolve their email address. The error message stated:
"The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message."
The solution is to either synchronize all Active Directory containers holding objects likely to send and receive email, or simply move the objects in question to one of the OUs being synchronized with Office 365 (Windows Azure AD).
I chose the second option. Once this was completed, all members of the organization, both migrated and non-migrated, could communicate by email.
Problem 2 (and 3)
Problems 2 and 3 are unlikely to be encountered in a production environment but possibly in a practice network. My practice network accesses the Internet via an IP address dynamically assigned by my ISP. Inbound mail flow is achieved with a product called "No-IP" that dynamically adjusts DNS records, the MX records in particular, as the DHCP assigned IP addresses change.
However, many spam filtering services, such as SpamHaus, block email sent from dynamically assigned IP addresses.
This problem was resolved, at least temporarily, by a request sent to Microsoft tech support to unblock the IP address or whitelist the domain name. At this time, it is not clear which option was selected since the IP address is still the same. If the IP address changes (as it will) and mail still flows from point to point, we could assume that the domain name was whitelisted.
In any event, at the time of this writing, mail flow is successful in all directions and between all recipients.

Exchange 2007 (SP3) - migration (staged) - Exchange Online (Office 365) - Part 6 - Assigning licenses

This will be a short but essential post about assigning licenses to Exchange Online users.
So far, we have accomplished the following:
  • We have synchronized the user accounts (as well as contacts and groups) in our onsite Active Directory with Windows Azure Active Directory (the directory used by Office 365).
  • We have migrated certain mailboxes to Exchange Online (or to the "Cloud").
However, migrated users cannot use their mailbox until they are assigned a license, purchased for them when the Office 365 account was created (and yes, licenses can be purchased later as needed).
In this post, we will simply assign the purchased licenses to our two migrated users.
1. Logon to the "Office 365 admin center":

Select "licensing" on the menu at the left and then "subscription". In this section, and in the "licenses" section, we can see what type of subscription we have and how many licenses. We can also see payment options, auto-renewal options and pricing details.
Under licenses, we can see how many are assigned:
At this point, no licenses are assigned.
So how do we assign a license?
2. Go to "Users and Groups" (in the main menu on the left), then to "Active Users".
Select the user to whom a license should be assigned:

3. Over the to far right, click on the "pencil" icon to edit user properties:

Note: this is on the same screen as the previous image but I took two screenshots for better resolution. Larger screenshots tend to have lower quality resolution when posted in the blog.
4. Assign a license from the available licenses and license plans.

5. Assign a role and configure sign-in status:

6. Under "licenses | licensing" (main menu on left), note the updated licensing status:

Now licensed users can logon and access their email at the following URL:
Note: you may be redirected to this URL for logon (which is perfectly normal):

After logon, you return to the original URL.
In any event, the (licensed) user can now access email (via OWA in this case):