Ok, so I was thinking (which is always a very dangerous thing!) – after my last post on how you can programmatically count Mailboxes per Exchange Database – I was wondering how you can programmatically get a list of all Exchange Mailbox Databases in Active Directory via their distinguishedName.

Why was I thinking this? – well, if you were interested in – or – read my last article you would have noted that in order to “count” the Mailboxes within each database you had to supply (from the command line) the distinguishedName of each Mailbox database to the code.

Now, I am all about automation – so I wanted to define a way where the same code (from my previous post) could be executed to display the same data without the need for command line arguments – e.g the mailbox counts per database without the user having to provide the distinguishedName.

So, I had a good old session on MSDN and eventually found this code sample which gave me what I needed. In essence I knew that I wanted to be able to search the Active Directory “Configuration Partition” in the same way as I did with the “Domain Partition” (where the Domain contains properties and attributes for user account objects (amongst other things)).

The idea was if I could get the distinguishedName of a Mailbox Database from the AD Configuration Partition using an LDAP filter and then pass the result to a LDAP search of the “Domain Partition” partition based on the “homeMDB” attribute (see last post) – then I could automate the entire process – therefore negating the need for command line arguments.

So I have added the following function to he code:

static void GetMailboxDatabases()
        {
            
            DirectoryEntry RootDSE = new DirectoryEntry("LDAP://RootDSE");
            DirectoryEntry ConfigContainer = new DirectoryEntry("LDAP://" + RootDSE.Properties["configurationNamingContext"].Value);
            
            DirectorySearcher ConfigSearcher = new DirectorySearcher(ConfigContainer);
            ConfigSearcher.Filter = "(&(objectClass=msExchMDB))";
            ConfigSearcher.PropertiesToLoad.Add("distinguishedName");
            ConfigSearcher.PageSize = 10000;
            ConfigSearcher.SearchScope = SearchScope.Subtree;


            foreach (SearchResult result in ConfigSearcher.FindAll())
            {
                
                GetDatabaseMailboxCount(result.Properties["distinguishedName"][0].ToString());

            }
        }

As mentioned – the function above is based upon a generic MSDN article – which I have made a few modifications to – these are:

• The original MSDN code performs an LDAP search of the Configuration Partition in AD (which also contains a number of Exchange specific attributes when Exchange is installed) – I changed the LDAP search filter to:

(&(objectClass=msExchMDB)

• I modified the PageSize to 10000 – to ensure that the traversal of the AD tree was deep enough (in large environments this *might* need increasing).
• Modified the SearchScope to SubTree – to ensure that all levels of the configuration partition are traversed during the search.
• Added in a “foreach” loop as we expect multiple results (e.g. more than one Database) to pass the Database DN to the DatabaseMailboxCount function.

The modified code

The original code needed arguments from the command line when compiled – the revised code (below) works like the following:

• Does not need the Mailbox Database Distinguished Name to be passed from the command line.
• Only gets “real” mailboxes (e.g. no System or Health Mailboxes).

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.DirectoryServices;

namespace GetDatabaseMailboxCount
{
    class Program
    {

        /*
         Define a function that gets the Root Directory Entry Path.
         This is used by other functions to return the default naming context:
         LDAP://DC=artTest,DC=local
         */

        public static DirectoryEntry GetDirectoryEntry()
        {
            try
            {
                DirectoryEntry Root = new DirectoryEntry("LDAP://RootDSE");
                string Domain = (string)Root.Properties["defaultNamingContext"][0];

                DirectoryEntry DirectoryENT = new DirectoryEntry();

                DirectoryENT.Path = "LDAP://" + Domain;
                DirectoryENT.AuthenticationType = AuthenticationTypes.Secure;

                return DirectoryENT;
            }
            catch (Exception ex)
            {
                Console.ForegroundColor = ConsoleColor.Red;
                Console.WriteLine("Failed to contact Active Directory with error: \n{0}", ex.Message);
                Console.ResetColor();
                return null;
            }
        }

        /*
         
         Define the function which Counts the Mailboxes per Database
         
         
         */

        static void GetDatabaseMailboxCount(string MailboxDN)
        {
            
            // Get the Directory Path
            
            string aDE = GetDirectoryEntry().Path.ToString();
            
            // Create a Directory Searcher Object Set to the Path

            DirectorySearcher search = new DirectorySearcher(aDE);

            string filter;


                // Otherwise filter out cn= starting with HealthMailbox or SystemMailbox
                
                filter = "(&(objectClass=user)(homeMDB=" + MailboxDN + ")(!(cn=HealthMailbox*))(!(cn=SystemMailbox*)))";
            
            search.Filter = filter;
            search.PageSize = 10000;
            search.SearchScope = SearchScope.Subtree;
            
            int Number = 0;

            // Count each result

            foreach (SearchResult result in search.FindAll())
            {
                Number++;
            }

         
            Console.ForegroundColor = ConsoleColor.Green;
            Console.WriteLine("Mailbox Database: " + MailboxDN + ":");
            Console.ForegroundColor = ConsoleColor.Cyan;
            Console.WriteLine("Contains " + Number + " Mailboxes");
            Console.ResetColor();

        }

        static void GetMailboxDatabases()
        {
            
            DirectoryEntry RootDSE = new DirectoryEntry("LDAP://RootDSE");
            DirectoryEntry ConfigContainer = new DirectoryEntry("LDAP://" + RootDSE.Properties["configurationNamingContext"].Value);
            
            DirectorySearcher ConfigSearcher = new DirectorySearcher(ConfigContainer);
            ConfigSearcher.Filter = "(&(objectClass=msExchMDB))";
            ConfigSearcher.PropertiesToLoad.Add("distinguishedName");
            ConfigSearcher.PageSize = 10000;
            ConfigSearcher.SearchScope = SearchScope.Subtree;


            foreach (SearchResult result in ConfigSearcher.FindAll())
            {
                
                GetDatabaseMailboxCount(result.Properties["distinguishedName"][0].ToString());

            }
        }

        static void Main(string[] args)
        {
            Console.Clear();
            GetMailboxDatabases();

        }
    }
}

Hope that helps!

Ok, I know that the above is pretty easy using Powershell. In fact it is possible to also implement this using Automation Runspaces (again executing Powershell cmdlets from within the C# project) to achieve the same thing. But for a program that I am writing at the moment I needed to take a slight different approach.

In essence I need to be able to quickly count all user mailboxes within a Exchange Mailbox Database and return them in a format of my choosing – for example; in the main program that I am writing the format would be an array which is then ported to the Data Grid control. I discovered that whilst this is a very simple task in pure Powershell – it is not that easy to convert into C# to accomplish my goal as described above.

To set the scene the Powershell cmdlets which can be piped together are as follows (referenced from: http://blog.dargel.at/2012/01/30/get-the-number-of-mailboxes-per-database/) :

(get-mailboxdatabase) | foreach-object {write-host $_.name (get-mailbox -database $_.name).count}

Which will give you an output similar to the following:

I found that encapsulating something similar to the above within C# presented me with two main issues:

• Execution time was lengthy – depending on the number of Mailbox Databases and Mailboxes.
• Formatting the results from the Automation Runspace into an array was not easy.

I had a look around the Internet to see if there was a native way using something like EWS to accomplish the same thing – but alas I could not find exactly what I wanted. So I decided to write something in C# which allowed me to achieve what I needed.

Essentially – whereas it is always preferable to use Powershell when interacting with or querying Exchange – most Exchange Objects – including Databases and Mailboxes are held within Active Directory. This means – that if we know a few Directory attributes which tie Mailboxes to Databases then we should be able to construct an LDAP search string using a DirectorySearcher (using the System.DirectoryServices Reference) and count the results.

So after some brief thinking, a few cups of coffee tea and a heavy session using ADSI Edit I decided on the following two Active Directory attributes:

• homeMDB – contained on each user object that has a mailbox.
• DistinguishedName – contained on all Mailbox Databases (and all other objects in AD – but I am interested in the DN on the Mailbox Database).

The homeMDB attribute on each user object in Active Directory is in fact the DistinguishedName of the Mailbox Database that contains the Mailbox object within Exchange – see below:

Mailbox Database Distinguished Name

AD User Object homeMDB

Given the above using an LDAP filter like:

(&(objectClass=user)(homeMDB=CN=Paris_Office,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=artTest,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=artTest,DC=local)(!(cn=HealthMailbox*))(!(cn=SystemMailbox*)))

Should return all users with a mailbox within the specified homeMDB. You will note in the example above I have excluded mailboxes with a CN= that starts “SystemMailbox” or “HealthMailbox” – using the following syntax:

(!(cn=HealthMailbox*))(!(cn=SystemMailbox*))

The output of the above LDAP query when testing in Active Directory Users and Computers looks like the following:

Now that I had the information that I needed from Active Directory and the correct LDAP query all I needed to do was convert that into C#.

Firstly I wrote a command line based test program which accepts the following parameters:

• Mailbox Database DN
  • e.g. CN=Paris_Office,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=artTest,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=artTest,DC=local
• Execution Mode
  • System – includes system and health mailboxes in the overall count from the database
  • nonSystem – only includes normal mailboxes

Therefore correct command line examples when the program was compiled would be (including the double quotes):

All mailboxes including system and health:

GetDatabaseMailboxCount.exe “CN=Paris_Office,CN=Databases,CN=Exchange Administrative Group(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=artTest,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=artTest,DC=local” System

Or if you want just normal mailboxes:

GetDatabaseMailboxCount.exe “CN=Paris_Office,CN=Databases,CN=Exchange Administrative Group(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=artTest,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=artTest,DC=local” nonSystem

The program (code supplied below) should be compiled using Visual Studio, using .NET 3.5 (or above) as a Windows Console Application with the System.DirectoryServices reference added to the project.

The Code

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.DirectoryServices;

namespace GetDatabaseMailboxCount
{
    class Program
    {

        /*
         Define a function that gets the Root Directory Entry Path.
         This is used by other functions to return the default naming context:
         LDAP://DC=artTest,DC=local
         */

        public static DirectoryEntry GetDirectoryEntry()
        {
            try
            {
                DirectoryEntry Root = new DirectoryEntry("LDAP://RootDSE");
                string Domain = (string)Root.Properties["defaultNamingContext"][0];

                DirectoryEntry DirectoryENT = new DirectoryEntry();

                DirectoryENT.Path = "LDAP://" + Domain;
                DirectoryENT.AuthenticationType = AuthenticationTypes.Secure;

                return DirectoryENT;
            }
            catch (Exception ex)
            {
                Console.ForegroundColor = ConsoleColor.Red;
                Console.WriteLine("Failed to contact Active Directory with error: \n{0}", ex.Message);
                Console.ResetColor();
                return null;
            }
        }

        /*
         
         Define the function which Counts the Mailboxes per Database
         
         
         */

        static void GetDatabaseMailboxCount(string MailboxDN, string sOP)
        {
            
            // Get the Directory Path
            
            string aDE = GetDirectoryEntry().Path.ToString();
            
            // Create a Directory Searcher Object Set to the Path

            DirectorySearcher search = new DirectorySearcher(aDE);

            string filter;


            if (sOP.ToLower() == "system")
            {
                Console.WriteLine("Checking including all Mailboxes");
                
                // If you want to include system and health mailboxes
                // configure LDAP query to look for all users with
                // the homeMDB attribute set the the passed MBDB DN

                filter = "(&(objectClass=user)(homeMDB=" + MailboxDN + "))";
            }
            else
            {
                Console.WriteLine("Checking excluding System and Health Mailboxes");
                
                // Otherwise filter out cn= starting with HealthMailbox or SystemMailbox
                
                filter = "(&(objectClass=user)(homeMDB=" + MailboxDN + ")(!(cn=HealthMailbox*))(!(cn=SystemMailbox*)))";
            }

            search.Filter = filter;
            search.PageSize = 10000;
            search.SearchScope = SearchScope.Subtree;
            
            int Number = 0;

            // Count each result

            foreach (SearchResult result in search.FindAll())
            {
                Number++;
            }

            // Write the results to the console

            Console.WriteLine("Mailbox Database: " + MailboxDN + " contains " + Number + " Mailboxes");

        }

        static void Main(string[] args)
        {

            Console.Clear();
            
            // Get the parameters from the command line

            string DN = args[0];
            string mode = args[1];
            
            // Pass them to the GetDatabaseMailboxCount function

            GetDatabaseMailboxCount(DN,mode);
        
        }
    }
}

Output from the Code:

If the program is executed with the nonSystem parameter the output should look like the following example – notice the Mailbox count for the database is at the end:

If the program is executed with the System parameter the output should look like the following example:

So how did the above help me?

Well the code contains the following basic logic:

• Accepts a Mailbox Database distinguishedName
• Counts all users with Mailboxes in that DB
• Outputs the DB name and the mailbox count
• Executes quickly

For me it will now be quite simple to modify the code to return the values to an array or list and then set that as the Data Source for a Grid View control. Which is exactly what I am now doing.

I hope that this helps someone out there who might be looking to the same or similar thing – and please feel free to modify the code how you see fit.

So as some of you will know I have been working on a number of programming projects over the last few years. Admittedly some are better than others – but the one thing that has always bothered me is how I can provide a better setup and configuration experience for my readers.

Most of my tools are pretty simple in terms of their installation – however there are a few which I have authored that have required a more involved setup process – usually I have handled this through user guides with step by step screen shots – or videos that I have published via my YouTube channel.

The ideal scenario would be for me to deploy my software via MSI using tools such as Install Shield, Install Aware – or my personal favourite – Advanced Installer.

It is important to note that all of these tools contain features which automate the following tasks during setup:

• Registering Services.
• Creating Application Pools in IIS.
• Creating Virtual Directories in IIS.
• Creating Service Account in Active Directory.
• Changing Group Membership.

However the above tends to be contained within the higher level “paid” versions which tend to be very expensive (for a single ad-hoc amateur developer like myself).

So with the above in mind, I decided to write a simple and small tool (which is probably of more interest to developers, rather than Exchange folks) which when combined with a purpose built setup tool (more on this below) – automates the creation and modification of the above.

This article will focus on the RCCT and how it can be used with Advanced Installer – you might be asking why I like Advanced Installer above setup studios? – well there are a few reasons – but the main two are:

• Advanced Installer has a completely free edition which allows for a process to be launched post install with Parameters (why I like this will become apparent very soon).
• Advanced Installer is very easy to use.

Other main tools (such as Install Shield or Install Aware) whilst being exceptionally powerful – do not offer a free version for non-profit use.

By combining the RCCT tool with Advanced Installer – I can package my software up into an MSI – and then execute a program at the end of the install with a number of parameters which gives me the following functionality of the “paid for” version.

• Basic IIS Configuration (creating Application Pools, Virtual Directories, assigning Virtual Directories to Application Pools).
• Creation of Accounts and modifying group membership in AD.

You can also use the RCCT as a stand alone command line tool.

Download

[ RCCT Tool – 38KB ]

Using the RCCT – Stand Alone

The RCCT expects the following mandatory command line arguments:

RCCT.exe <Service Account Name> <Service Account Password> <Service Account Description> <IIS Application Pool Metabase Path> <Application Pool Name> <IIS Virtual Directory Metabase Path> <Physical IIS Root Directory Path>

The command line example below will complete the following tasks:

• Create a user calls “svc_Test” in Active Directory.
• Set the password to “Password1”.
• Set the description on the AD account to “Demo Service Account” .
• Create an Application Pool called “ap_TestAppPool” within IIS.
• Create a virtual directory called “test_VDir” within the first website (determined by the IIS path provided) give it a physical path of “T:\testDir” and then assign the “ap_TestAppPool” to the virtual directory (making it an application).

RCCT.exe "svc_Test" "Password1" "Demo Service Account" "IIS://Localhost/W3SVC/AppPools" "ap_TestAppPool" "IIS://Localhost/W3SVC/1/Root" "test_vDir" "t:\TestDir"

There are some default actions that the tool also performs on the Virtual Directory:

• Sets the default page to “default.aspx”.
• Sets the default Security to NTLM.

These options are not configurable in this version.

The output from the above command looks like the following example:

The RCCT also accepts a final optional parameter which is a Windows Active Directory Group that you like to add the service account into. in the example below I have changed the command line to add the service account into the Domain Admins group:

RCCT.exe "svc_Test" "Password1" "Demo Service Account" "IIS://Localhost/W3SVC/AppPools" "ap_TestAppPool" "IIS://Localhost/W3SVC/1/Root" "test_vDir" "t:\TestDir" “Domain Admins”

You will see at the bottom of the screen shot above the following message:

GROUP DN PASSED: CN=Domain Admins

Using the RCCT – with Advanced Installer

Advanced Installer is provided by Caphyon and comes in five versions:

• Freeware
• Architect
• Enterprise
• For Java
• Professional

Naturally I make use of the free version. You can use the RCCT in conjunction with the [ Exit dialog –> After Finishing Actions –>Launch Application ] options – see below.

I hope that someone out there finds this useful – and I welcome any feedback or suggestions.

In January I released a very simple tool called ‘WinWOL’ (Windows Wake on LAN) which, as the name suggests is a Windows based Wake on LAN manager. Over the last few months I have been looking at the software again and wanted to change how it worked to make it a little simpler to use.

This resulted in a complete re-design of the user interface to adopt a ‘Tab based look and feel’ and a recompilation of the code against .NET 4.0 to allow for more people to be able to run the tool without necessarily having to update .NET on their machines.

Today I am pleased to announce the release of WinWOL version 1.1.

Quick Comparison

The following is a quick preview of the design changes between the two versions. You will notice that the updated design uses less screen real estate, and during usage automates a number of tasks – such as:

• One you have performed a IP Range Scan, selecting the host will automatically populate the details Win the WinWOL control section.
• Selecting a host from the “Remembered Host” section will populate various information in the WinWOL control section, double clicking on a remembered host will automatically send the ‘Wake’ packet.

Old User Interface

New User Interface

Download

You can download the WinWOL tool from the following location.

[ WinWOL – Version 1.1 – 170KB ]

User Guide

You can download the WinWOL installation and user guide from the following location.

[ WinWOL – Users Guide – 350KB ]

Change History

Version 1.0 – Initial Release

• Now retired

Version 1.1

• Complete interface re-design to allow for easier discovery and “waking” of remembered hosts.
• Re-compiled against version 4.0 of the .NET Framework.
• New Feature: Double click to wake feature added to the “Remembered” hosts window.
• New Feature: Added in name resolution of remembered hosts.
• Added in an ‘About Box’
• Enhanced error handling.
• New User and Installation Guide.

I guess that I never really finish a tool. There is always something that I can think of to add or a suggestion that someone makes that I want to code in! This is especially true for the Exchange Bulk User Creation Tool v2.0 (EBUCT) where hot on the heels of version 1.2 – I am now pleased to announce version 2.0.

The principal of the EBUCT remains the same – it is designed to allow for the bulk creation of mailboxes in Exchange 2013 – a feature that is currently missing from the Exchange Administrative Centre in Exchange 2013.

Key Changes in functionality

The good news is that I have not fundamentally changed the way in which the tool works for version 2.0.

What I have tried to focus on is streamlining the process of creating mailboxes as well as adding in the ability to search for specific Active Directory accounts from the returned list after you have clicked on the “Refresh” button.

Below is a comparison between the two interfaces which points out the major changes:

Old Interface (Versions 1.0,1.01 and 1.2):

New Interface

You will notice that the “Selected user accounts” window has now been removed from the EBUCT. Essentially you can now just select your desired users from the “Active Directory Users without Mailboxes” area by checking the box next to them.

Select the mailbox database and then click on the “Enable” button.

You will also see a new “Search Accounts” text area. You can type in the name of a specific account from the Tree after you have clicked on the “Refresh” button. The text area also allows for ‘Fuzzy’ searches – e.g. a few characters of the name and the EBUCT will try to locate it in the list.

I hope that you like the new version – and as always keep sending me your feedback. You can get version 2.0 from the downloads area below.

Download

[ EBUCT.exe – 720KB ]

Setup and Usage

To configure and use the EBUCT please refer to the following articles – please make sure that you take note of the changes that I have mentioned above for version 2.0 – setup, configuration and prerequisites between 1.2 and 2.0 are EXACTLY the same.

• http://www.telnetport25.com/2012/11/ebuctexchange-2013-bulk-user-creation-tool/

Revision History

Version 1.0.0.0 – 04/11/2012

• Initial release – now retired

Version 1.0.0.1 – 05/11/2012

• Second release – now retired
• Changed Interface “Select / Unselect all Mailboxes” to “Select / Unselect all Active Directory Accounts”
• Changed “www.telnetport25.com” located in the status bar to be an active and clickable URL
• Moved the enable mailbox process bar to be next to the enable button
• Added in a progress status label
• BUG FIX: Fixed Directory Accounts with special characters within the name (samAccountName) were not processed correctly
• BUG FIX: The “Select / Unselect all Active Directory Accounts” check box was not unchecked when all processing had been completed

Version 1.2.0.0

• Third release – now retired.
• Re-compiled the tool so that it will run with version 4.0 of the .NET Framework, some people reported issues with 4.5 as they were not running it.
• Added in Event Logging Diagnostics: The EBUCT creates an Event Log under Applications and Services called ExchangeEBUCT – relevant information from the tool is logged here

Version 2.0 – 26/04/2013

• Redesigned interface to make the software more simple:
• Removed the need to select Directory users from the from the “Active Directory Users without Mailboxes” to the “Selected Users section”. You can now just check the accounts in the Treeview.
• Added in a ‘File’ menu which allows for the application to be exited from a menu command.
• Added in an ‘About’ box.
• Flattened the user interface buttons.
• New Feature: Search for a specific account within the Active Directory Treeview.
• Error Handling: Added in some enhanced error handling scenarios which in previous versions could result in the tool raising an Exception.
• Error Handling: Program will notify you if you try and enable an account without having selected a Mailbox Database.
• Error Handling: Program will notify you if you have not selected at least one Active Directory Account.

Ok, yes I know – I said that Part 8 was the last in this particular series – but then Microsoft went and released Cumulative Update 1 (CU1) for Exchange 2013 (on April 2nd) which left me feeling that if I did not cover this – then the LAB series was not properly completed. For those of you who are just joining us – you can find links to the previous parts below.

Part 1

We established our domain design, covered how to provision the Domain Controller for the LAB in Hyper-V and then how to install Windows Server 2012 on the Domain Controller.

Part 2

We went through the process of installing Active Directory Domain Services on the LAB domain controller using PowerShell.

Part 3

We covered how you can install a very simple PKI infrastructure on the domain controller using Active Directory Certificate Services. These will be used in a later part to configure SSL for various parts of Exchange 2013.

Part 4

We covered how to use PowerShell to provision Exchange server VM’s in the lab, and went through the pre-requisite software installation.

Part 5

We covered the Directory, organisation and Exchange preparation – and then went on to install the relevant Exchange servers using the unattended setup feature.

Part 6

We covered Database Availability Groups and provided a script which automates the creation of DAGs from a CSV.

Part 7

We covered adding databases to the DAG and configuring SSL.

Part 8

We covered the creation of user accounts in Active Directory then using EBUCT tool to create the user Mailboxes, then the creation of a number of Distribution Lists rounded off with the creation of “Modern” Public Folders.

What is Cumulative Update 1 – in fact, what are Cumulative Updates?

For more detailed information on CU1 for Exchange have a look here at the launch announcement.

The Cumulative Update Servicing model is new to Exchange, but not a new concept. People who have worked with Lync server will be very familiar with the concept. From Exchange 2007 many of you will be know that Exchange used Role Up’s as interim collections of “hotfixes” with the occasional feature change between Service Packs ~ however for Exchange 2013 updates will be quarterly using the Cumulative Updates Service model.

Each CU is a full Exchange standalone image, which means that it cannot be uninstalled (unless you remove all of Exchange) and should a CU fail part of the way through – you will have to recover the Exchange Server using the /M:RecoverServer – again this is not new as the traditional Exchange Service pack used this model. Service Packs are still likely to be provided periodically.

One other thing to note is that with each CU being a full Exchange image, unlike Roll Ups they can also be used to install the full version of Exchange Server. If you would like to read more about this have a look here

Upgrading to CU1

Before I get into the process of performing the upgrade to the lab – it is probably worth you having a read of the article that I wrote here about some additional steps that I have found over the years that can help ensure that an upgrade goes smoothly – in particular the bit about ensuring there are no reboots outstanding.

There is another good article here which is worth reading about the upgrade process by fellow Exchange MVP Paul Cunningham:

• Paul Cunningham – http://exchangeserverpro.com/exchange-2013-installing-cumulative-updates/

As this is a LAB I will leave it up to you if you go through the steps of backing stuff up (just remember in production that is a mandatory step!) – so without any further “ado” – lets get to the upgrade process.

The process for the artTest.LAB

The upgrade order should be as follows:

1. art-MBXCAS-01 – Client Access and Mailbox
2. art-MBXCAS-02 – Client Access and Mailbox
3. art-MBX-01 – Mailbox Server

Therefore log onto art-MBXCAS-01 and download the Exchange 2013 CU 1 update from: http://www.microsoft.com/en-us/download/details.aspx?id=38176. When you have downloaded the binary double click on it to extract the installation to a location on the server.

Before we begin the process of updating the Schema, preparing AD and then the domain we should put art-MBXCAS-01 into maintenance mode as the CU prerequisites check is known to stop the transport services. In order to do this you should execute the following Powershell Commands (thanks to fellow MVP and Exchange Certified Master Brian Reid for the expanded syntax for each command – please visit his blog for the original article on which these are based)

Open an Exchange 2013 PowerShell command prompt and type each of the following commands:

Set-ServerComponentState $env:COMPUTERNAME -Component HubTransport -State Draining -Requester Maintenance

Redirect-Message -Server $env:COMPUTERNAME -Target art-mbxcas-01.artTest.local

Suspend-ClusterNode $env:COMPUTERNAME

Set-MailboxServer $env:COMPUTERNAME -DatabaseCopyActivationDisabledAndMoveNow $True

Set-MailboxServer $env:COMPUTERNAME -DatabaseCopyAutoActivationPolicy Blocked

Set-ServerComponentState $env:COMPUTERNAME -Component ServerWideOffline -State Inactive -Requester Maintenance

Get-ServerComponentState $env:COMPUTERNAME | Format-Table Component,State –Autosize

Get-MailboxServer $env:COMPUTERNAME | Format-Table DatabaseCopy* –Autosize

Get-ClusterNode $env:COMPUTERNAME | Format-List

You can save time by copy and pasting each of the above commands into a PowerShell script file (which I have done in the screenshot below) and then executing that from the Exchange Management Shell. Alternatively you could also make use of Michael Van Horenbeeck’s rather excellent automated script which you can get from here.

If you do choose to use a script file – remember the guidance that I provided here to execute script file from the Exchange Management Shell.

One the server has been placed in maintenance mode we are ready to begin the process of updating the LAB’s directory environment. From the location where you extracted Exchange 2013 CU1 binaries open an administrative command prompt and type in the following command:

Setup.exe /PS /IAcceptExchangeServerLicensingTerms

Note: If you do not include the /IAcceptExchangeServerLicensingTerms parameter setup will halt (yes I know its a pain)

Setup will then begin the process of upgrading the Schema – see below.

When the Schema has been upgraded you will then need to run the following command

Setup.exe /PrepareAD /IAcceptExchangeServerLicensingTerms

Just so you know I am going by the release notes here – normally I would have expected the /PrepareAD switch to prepare the schema and the domain – but I did not get the chance to test this idea, so I stuck to the Microsoft provided guidance.

The output of the /PrepareAD switch is provided below.

As the final part of preparing Active Directory you should execute the following command line:

Setup.exe /prepareDomain /IAcceptExchangeServerLicensingTerms

The output of which is provided below.

After the directory preparation has been completed – You should now be in the position to upgrade the Exchange install on art-MBXCAS-01 server. From the command prompt type in the following command:

Setup.exe /m:Upgrade /IAcceptExchangeServerLicensingTerms

Setup will then begin the process of upgrading the Exchange installation on the server.

When Setup has completed I recommend that you reboot the server even if you are not prompted. There has been some discussion on a few mailing lists that I am a member of which suggests that the unattended setup should always prompt you to reboot but is not doing so (whereas the GUI setup does) – I have been seeing this as well.

When you have rebooted the server you need to return is back to normal operation (take it out of maintenance mode) by using the following PowerShell commands from within the Exchange Management Shell (again thank you goes out to Brian Reid for these command lines).

Set-ServerComponentState $env:COMPUTERNAME -Component ServerWideOffline -State Active -Requester Maintenance

Resume-ClusterNode $env:COMPUTERNAME

Set-MailboxServer $env:COMPUTERNAME -DatabaseCopyActivationDisabledAndMoveNow $False

Set-MailboxServer $env:COMPUTERNAME -DatabaseCopyAutoActivationPolicy Unrestricted

Set-ServerComponentState $env:COMPUTERNAME -Component HubTransport -State Active -Requester Maintenance

You can, like with the commands to place the server into maintenance mode copy these commands into a PS1 script file and execute them from within the Exchange Management Shell (which is what I have done in the screenshot below).

You are now ready to move onto art-MBXCAS-02 and then finally art-MBX-01 (remember to upgrade art-MBXCAS-02 before art-MBX-01). You also do not have to repeat the Active Directory preparation steps. Ensure that after the upgrade has completed and you have rebooted the server to take it out of maintenance mode.

Right, that is that certainly for this series. There will of course be further Exchange 2013 shenanigans that I write – but I think, as Gordon Ramsey would say – Done!.

Wow, and I really mean wow! – here in the UK it has been a 4 day holiday due to Easter ~ However, to round off what has been a very cool four days with my family – I received the following e-mail just a few moments ago from Microsoft:

Dear Andy Grogan,
Congratulations! We are pleased to present you with the 2013 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Exchange Server technical communities during the past year.

I am – again – so pleased and very surprised (I think that each year I am surprised – as at a personal level I always think that I can give more back) that I have been considered to have maintained the required standard to be renewed by Microsoft and the wider community.

Each year – as for most people – has brought many challenges for me personally, again – as per the last award cycle I changed jobs twice (mainly as I have been very indecisive about what I actually want to do within IT).

The last time that I posted about the MVP award was last year – for my fourth where I had just started in a new position within a new company as a very hands on CTO.

I stayed in that role for 6 months (it was a good company ~ but something was missing) – so when I was lucky enough to be offered a new role as Head of Technical delivery for a 15,000 user organisation with a large technical team I had to take it as I thought the scale offered me the chance to really change something – this was perhaps the missing link that I was looking for.

I knew that by accepting this assignment I would not be as “hands on” as I had in mind – but the truth was that I was trying to have my cake and eat it. I felt that the new job offered me a good balance between being highly technically aware – but influence strategy and service delivery ~ a rare and exiting challenge indeed!.

Thankfully my initial gut feelings seem to have been right – as now seven months in, I am enjoying what I do again ~ working with some wonderfully talented people and engaging at a very deep level with a number of the leaders within the industry to aid our technical direction.

Of course this means that when compared to some of the other Exchange guys out there (Steve Goodman, Paul Cunningham, Tony Redmond, Nino Mota ~ plus many others to numerous to mention) I am not as on the ball as I would like to be when compared to these chaps – but I have been trying to cut out my little niche with the time that I have by developing odd Exchange administrative tools – therefore to have been recognised again means so much to me personally.

Many of the names above have continued to keep my passion for Exchange and giving back to the wider community alive (most recently Steve and Tony for various reasons (Steve for being a true gent, and Tony for completely living up to his title as the “god father” of English based MVP’s)).

Anyhow, I still have not lost sight of what gives me any form of credibility (if I had any to start with) or support which is the readers of www.telnetport25.com. Each year the fact that you read, contribute and keep me “honest” is the only reason why I can have the privilege of writing a post such as this – so, once again – and for the fifth time my sincere thanks for all of your continued support!

I have some big plans (well I say “big” ~ ideas) for www.telnetport25.com over the next year – and I look forward to you all coming along with me.

Once again, thank you all so much – and I look forward to keeping the site going over the next year.

Just to sign off, my dad passed away six years ago in May and as I mentioned back in 2009 when I was first awarded – this would not have ever happened without him as he gave me the confidence to “give it a go” ~ thanks dad, I said back then; “this one is for you” – and it still is!

Ok, we are now in the final straight in this series with this being the final part of creating a test lab from scratch with Windows Servers 2012 and Exchange 2013. I could in truth perhaps go on forever as there are loads of things that I have not covered. But that is the beauty of a test lab, once you have one that is up and running – it is yours to do with as you choose and that is what I hope that you will all do .

For those of you who are joining us at this stage you can find the previous 7 parts below.

Part 1

We established our domain design, covered how to provision the Domain Controller for the LAB in Hyper-V and then how to install Windows Server 2012 on the Domain Controller.

Part 2

We went through the process of installing Active Directory Domain Services on the LAB domain controller using PowerShell.

Part 3

We covered how you can install a very simple PKI infrastructure on the domain controller using Active Directory Certificate Services. These will be used in a later part to configure SSL for various parts of Exchange 2013.

Part 4

We covered how to use PowerShell to provision Exchange server VM’s in the lab, and went through the pre-requisite software installation.

Part 5

We covered the Directory, organisation and Exchange preparation – and then went on to install the relevant Exchange servers using the unattended setup feature.

Part 6

We covered Database Availability Groups and provided a script which automates the creation of DAGs from a CSV.

Part 7

We covered adding databases to the DAG and configuring SSL.

Part 8

In this part I will be covering:

• The creation of user accounts in Active Directory.
• The creation of Mailboxes.
• The creation of Distribution Lists.
• The creation of “Modern” Public Folders.

In addition to the above I will also cover some further reading that you might want to do on your own in regard to making your OWA CAS configuration highly available.

For this part, you will need to download the following scripts and tool from www.telnetport25.com (anyone would think that I had a plan when I wrote all of these ~ ok, no I didn’t but it seems that way now).

• Lab users creation script and CSV: http://www.telnetport25.com/2011/12/update-to-my-create-lab-users-powershell-scriptmultiple-domains-and-500-more-users/
• The Exchange 2013 Bulk users creation tool: http://www.telnetport25.com/2012/11/ebuctexchange-2013-bulk-user-creation-tool/
• Distribution Lists Creation Script and CSV: http://www.telnetport25.com/2011/07/quick-tipcreating-distribution-groups-from-a-csv-file-using-powershell-for-a-lab-environment/

I do not intend to cover how to use these scripts and tools in any depth whatsoever in this article as I have covered the specifics of the operation of each in their own respective posts.

Creating Users

In order to create around 500 or so users ready to be placed within the relevant databases run the Create Users script (which you can get from the link above) – when prompted – select the relevant users CSV file from the browse dialog box – see below.

When the script has completed – you will be presented with a message explaining that the execution has completed. You will then be able to find all of your users within an OU called “Exchange Users” in Active Directory Users and Computers – see below.

Creating Mailboxes

The EBUCT (Exchange Bulk Users Creation Tool) – is available from the download link above. Download it to one of the servers in your LAB and fire it up. Click on the “refresh” button to populate the AD accounts section, and then choose each of the accounts that you want to put in each Mailbox Databases; when ready click on “Enable” – then repeat the process as required – see below.

If you then drop into the Exchange Administrative Centre you should now see all of your mailboxes.

Creating Distribution Groups

Very similar to the LAB Users Creation Tool – the Distribution Lists script operates in the same way – run the script, and select the relevant CSV file – see below.

The script will create a sub-OU under the ExchangeUsers OU called “DistLists” – in here you will find the Distribution Lists that the script created.

When the script has completed – you will be presented with the “Completed” message – see below.

Creating “Modern” Public Folders

Exchange 2013 introduces what is perhaps the first “major” architectural changes to Public Folder databases in … well … forever! I would say that the biggest leap is now the concept of Public Folder replication is now dead in the water (thankfully). “Modern” Public Folders now share the same high availability and storage technologies as the mailbox store. In fact – the Public Folder hierarchy is in fact a special mailbox contained within a mailbox store which can be part of a DAG.

There are of course other changes (administration and the like) and you need to be aware that you cannot in the RTM of Exchange 2013 access public folders from Outlook Web App.

Create Public Folders Script

Creating Exchange 2013 Public folders are not very hard to create in Exchange 2013 via either the Exchange Management Shell of Administrative Centre. However, as I mentioned in previous articles my aim in this series has been to provide you with examples where appropriate of using the shell.

The script performs the following actions within the LAB environment:

• Get the full list of available Mailbox Databases and presents the as options as the destination location for the Public Folder Mailbox Hierarchy.
• Creates Public Folders for Dublin, Paris and London within the hierarchy.

<#
    Exchange 2013 LAB - Create "Modern" Public Folders

http://www.telnetport25.com

    Author: Andy Grogan
    Version: 0.1
    
    .Compatibility
    
    Windows Server 2012
    Powershell 3
    Exchange 2013
    Not Supported with any other versions of the software mentioned above.
    
    .Parameters
          None
     
    .Example
        .\CreatePublicFoldersLab.ps1
    
#>

$MailboxDatabases = Get-MailboxDatabase | Select -expandProperty Identity 
$Count = -1
Write-Host "Create Public Folders" -ForeGroundColor Cyan
Write-Host ""


foreach($DB in $MailboxDatabases){
    $Count ++
    Write-Host "$Count . " $DB
}
Write-Host ""
$DBChoice = Read-Host "Please select a mailbox database where you would like to locate the public folders"


New-Mailbox -publicFolder –Name "artTest_PFHierarchy" –Alias "artTest_PFHierarchy" –Database $MailboxDatabases[$DBChoice]
New-PublicFolder -Name "London_Office"
New-PublicFolder -Name "Paris_Office"
New-PublicFolder -Name "Dublin_Office"

Write-Host ""
Write-Host "Script has completed..." -ForeGroundColor Green

Script Download

[ CreatePublicFoldersLab.ps1 – 1.1KB ]

Running the script

Either download the script to a location on one of the LAB Exchange servers or copy and paste it from the code block above. Open an Exchange Management Shell and type in:

.\CreatePublicFoldersLab.ps1

From the Mailbox options list – select a destination by typing in the corresponding numeral:

The script will then create the hierarchy and the relevant public folders:

OK, so how do I make the Client Access Servers Fault Tolerant in the LAB?

So there have been a number of changes in Exchange 2013 – not least of which are how clients connect to the respective Exchange infrastructure.

Before we get into that – lets have a look at the changes in the roles architecture. From Exchange 2007 and in Exchange 2010 we had the following discrete roles:

• Mailbox Server
• Hub Transport
• Client Access
• Edge Transport
• Unified Messaging

In Exchange 2013 – these roles have been consolidated down into:

• Mailbox Server
• Client Access Server

You might be thinking that this is very reminiscent of the good old Exchange 2003 days of Front End Servers (FES) and Mailbox Servers, which you would be sort of right – but it would be true to say that the concept has advanced significantly.

In Exchange 2013 the Mailbox server performs the following functions:

• Mail routing
• Voice Mail
• Renders Web Service based content

The Client Access Server Role performs the function of authenticating and routing client requests to the correct Mailbox Server. One key concept that has changed with the Client Access Server is that it no longer performs the rendering of OWA – it is in essence a reverse proxy. It will authenticate a user, direct them to the correct mailbox server and then hand offs everything else from that point onwards.

One other major change is that clients now connect purely over HTTPS (MAPI via RPC is gone).

With these changes – the concept of Load Balancing Exchange has also changed. Affinity now works as intended – it now does not matter if a client request hits another client access server it is still rendered by the mailbox which hosts the mailbox – therefore there is not performance degradation. With form based authentication the authentication cookie is provided to the client post logon which is encrypted using the SSL certificate of the given CAS server.

The logged on user can then maintain authentication on another CAS without having to be re-authenticated if there is a shared certificate between the Client Access Server.

All of the above means that you have a lot of flexibility in terms of the “Load Balancing” technologies that you can realistically make use of.

Broadly speaking – these fall into the following options:

• Round Robin DNS – we will be covering this in this post, I would recommend this in Test Labs where budget is tight – but not in Production as it is technically not true load balancing, and is a little “flaky” to say the least.
• Windows Network Load Balancing (WNLB) – Can be used in production (but again I would not recommend it) – remember that you cannot have WNLB and Failover clustering on the same server – therefore; NLB is not possible in our LAB without major modification.
• Third Party Load Balancing product – KEMP, LOADBALANCER.org etc. -  These are highly recommended for production scenarios.

Setting up Round Robin DNS

Logon to your Windows 2012 Domain Controller and open the DNS management MMC. Right click on the name of your LAB domain controller and from the context menu that appears choose “Properties”.

From the dialog that appears, click on the “Advanced” tab – ensure that the “Enable round robin” check box is check from within the Server Options section – see below.

Now you need to add in additional DNS [A] records for the relevant web services that we created in part 7 – to recap these were:

• OWA
• Mail
• Autodiscover

You can either do this from the DNS Manager MMC – or, like we did in part 7 use Powershell via the following cmdlet.

Add-DnsServerResourceRecordA

If we look at the topology of our LAB so far we have the following Client Access Servers:

• art-MBXCAS-01 = 172.31.253.108
• art-MBXCAS-02 = 172.31.253.109

So that means that we need two DNS records for the above DNS entries – so you are looking to have the following records on your DNS server:

This will give you a very basic level of fault tolerance using Round Robin DNS – but if you are looking for something more sophisticated then you should have a look at a commercial Load Balancing option; especially if you are planning on moving what you have learned in this series in to production at any point.

So to finish up in this series – it is probably worth looking conceptually at what we have created diagrammatically – here we can see the whole configuration – right from the Virtualisation host – all the way through to the virtual machines, database availability groups and CAS Load Balancing from the client end.

To Conclude

You might be thinking where to next? Well – that is up to you – I have not covered absolutely everything possible with your LAB – and indeed there is lots that can be changed / improved – but the point is that I am hoping that you are in position to begin to “tweak” the configuration. I will be continuing in future posts to add to this LAB (you may see its name crop up ) – but I urge you all to play around as much as you can.

I also hope that you have found this series useful and I am more than happy in receiving any thoughts that might wish to share.

I have been adding a few features to the Distribution List Reporting Tool which I thought that would be useful and I am pleased to announce that I think that it is ready. Hope that you like it.

Change History

Version 1.0

• Initial release

Version 1.1

• Added in handling for environments where there are no distribution lists
• Added in handling for environments where there is only one distribution list
• Added in handling for lists that contain either no or only a single membership entry
• Added in an event debugging information field at the bottom of the main page

Version 1.2

• Added in handling for lists that contain spaces within their names
• Modified the version number on the logo to 1.2
• Added a “sort” button for the lists on the main page – this sorts the names Alphabetically

Version 2.0

• Modified Member list rendering engine from a list control to GridView when querying a single list
• Added in bulk reporting on all lists which contain members with new GridView renderer
• Added in bulk reporting on lists that contain no members with new GridView renderer
• Added in support for Distribution lists which have members in multiple domains
• Redesigned user interface
• Added in the ability to export list membership to a CSV file
• Bug Fix: Fixed the incorrect reporting of lists that contain a single nested Distribution Group
• Improved error and report handling than that in version 1.2

Version 2.5

• Added in reporting for Dynamic Distribution Groups.
• Added in view the properties of the Distribution Lists.
• Added in view mailbox properties.
• Small modifications to the look and feel of the application.

Download

The installation binaries below can be used to perform both new installs and upgrade versions (e.g. run the setup executable and install over the top) – the IIS and Active Directory configuration remain the same if you have installed a previous version.

I have also included a full Installation and Users Guide within this download section.

  [ Distribution List Reporting Tool – Version 2.5 – 190KB ]

[ DLRT Installation and Users Guide – 1.3MB ]

Installation and Users Guide

Please see the PDF download in the download section.

Updates

Support for Dynamic Distribution Lists

Version 2.5 now includes support for reporting on single Dynamic Distribution Lists. You will see a new button at the top of the screen entitled “Dynamic”.

Dynamic Distribution List Properties

You can also review the properties of a dynamic distribution list by click on the folder next to the distribution list name.

Group and User Properties

You will see that there are a couple of new buttons within the interface – these allow for you to expose relevant properties of both Distribution Groups and Mailbox properties.

Example of Group Properties

Example of Mailbox Properties

Wow – part 7 – this is now (I think) officially the longest running series that I have written and not forgotten to finish it (don’t worry this is not the end, there is one more part to go). Took a little while to get this one off the deck as there are a few steps in this post that we need to go through. In retrospect I should have perhaps done a video for this – but I am trying to work through a “lip smacking” problem that someone commented on you of my “You Tube” videos that has left me a little self conscious. Actually it hasn’t – I don’t care – I just didn’t think of doing one .

To recap – the previous parts (should you wish to read them, refresh or catch up) can be found below:

Part 1

We established our domain design, covered how to provision the Domain Controller for the LAB in Hyper-V and then how to install Windows Server 2012 on the Domain Controller.

Part 2

We went through the process of installing Active Directory Domain Services on the LAB domain controller using PowerShell.

Part 3

We covered how you can install a very simple PKI infrastructure on the domain controller using Active Directory Certificate Services. These will be used in a later part to configure SSL for various parts of Exchange 2013.

Part 4

We covered how to use PowerShell to provision Exchange server VM’s in the lab, and went through the pre-requisite software installation.

Part 5

We covered the Directory, organisation and Exchange preparation – and then went on to install the relevant Exchange servers using the unattended setup feature.

Part 6

We covered Database Availability Groups and provided a script which automates the creation of DAGs from a CSV file in preparation for…

Part 7 (bam! ~ back with a vengeance)

In this part I would like to cover:

• Creating DAG Enabled Mailbox Databases
• Configuration the relevant Autodiscover, EWS and Exchange web based URLS using the Active Directory Certificate Services that we installed in Part 3

Create Mailboxes Script

Configuring Mailbox Databases in Exchange 2013 is not very hard – but in the spirit of this series where I have been trying to show how you can use Powershell to automate most tasks I have written the following script which performs the following:

• Creates Mailbox Databases from the command line.
• Sets the Offline Address Book to the “Default Offline Address Book”.
• Mounts the new database.
• Creates a copy of the new database on each node within the DAG.

You can copy and paste the script from this webpage into a new PS1 file on any of the Exchange Servers that we have created in this LAB – or you can download it from the download link below.

<#
    Exchange 2013 LAB - Create Mailbox Databases and Add Copies Script

http://www.telnetport25.com

    Author: Andy Grogan
    Version: 0.1
    
    .Compatibility
    
    Windows Server 2012
    Powershell 3
    Exchange 2013
    Not Supported with any other versions of the software mentioned above.
    
    .Parameters
        -DBName
        -DBPath
        -LogFilePath
       
    
    .Example
        .\Create2013LabDBs.ps1 -DBName <DatabaseName> -DBPath <Path to database> -LogFilePath <Path to Log Files>
    
#>

[CmdletBinding()]
Param(
    [Parameter(Mandatory=$True)]
    [string]$DBName,[Parameter(Mandatory=$True)]
    [string]$DBPath,[Parameter(Mandatory=$True)]
    [string]$LogFilePath
)

$LocalServerName = $ENV:ComputerName

function create_Databases{
     Write-Host "Creating Database - " $DBName -foregroundcolor White
    New-MailboxDatabase -Name $DBName -EDBFilePath "$DBPath\$DBName.edb" -LogFolderPath $LogFilePath -Server $LocalServerName
    Mount-Database -id $DBName
    Write-Host "Setting Offline Address Book" -foregroundcolor Cyan
    Set-MailboxDatabase $DBName -offlineAddressBook "Default Offline Address Book"

}

function create_FolderStructure{

    if(!(Test-Path $DBPath)){
        Write-Host "Database Folder Path Not Found - Creating." -foregroundcolor Green
        New-Item $DBPath -Type Directory
    }else{
        Write-Host "Database path found." -foregroundcolor Cyan
    }
    
    if(!(Test-Path $LogFilePath)){
        Write-Host "Log Folder Path Not Found - Creating." -foregroundcolor Green
        New-Item $LogFilePath -Type Directory
    }else{
        Write-Host "Log path found." -foregroundcolor Cyan
    }
    
}

function add_databaseCopies{
    
    $MailboxServers = Get-MailboxServer | Select -expandProperty Name
    
    foreach($SVR in $MailboxServers){
        if(!($SVR -eq $LocalServerName)){
            Write-Host "Adding Databases Copy for - " $DBName -foregroundcolor White
            Add-MailboxDatabaseCopy -id $DBName -MailboxServer $SVR 
        }
    }
}

create_FolderStructure
create_Databases
add_databaseCopies

Write-Host "Script Completed..." -foregroundcolor Green

Download

[ CreateMailboxDBS.ps1 – 2.1KB ]

UPDATE – 29/03/2013: A reader of this site requested a CSV enabled version of the above script – I have included it below with a sample CSV file should you wish to further automate the process of Mailbox Database Creation.

[ CreateMBXDBsCSV.ps1 – 2.6KB ]

[ sampleMBXDBCSV.csv – 1KB ]

Execute the script from the command line (with no parameters) and you will be asked to navigate to the location of the CSV file which contains the Mailbox Database Information – the script will then create the databases and add the mailbox database copies.

Creating DAG Enabled Mailbox Databases

Before you execute the script, and you have downloaded it from the link provided above you will need to ensure that the Execution Policy is set to allow for scripts to be run from the internet. If you have been following this guide – this should already be in place – but just in case; please refer to the following article: http://www.telnetport25.com/2012/02/quick-tip-running-exchange-based-powershell-script-files-from-the-command-line-or-a-batch-file/

For the purposes of the LAB, using the script we shall create the following databases:

• London_Office
• Paris_Office
• Dublin_Office

We will start with the London_Office. Open an Exchange Management Shell window and navigate to the location where you have stored the script. The script accepts the following command line parameters:

• -DBName / The name of the database – if you plan to use spaces please enclose this in inverted commas.
• -DBPath  / The physical path to the Exchange edb file – you do not need to provide the name of the database file as the script will create this for you – do not include a trailing slash at the end of the path.
• -LogFilePath / The physical path to the log files location.

You do not have to have created any folders for the logs or databases as the script will also create these for you.

Below is an example of the command line that I have used in my LAB to create the London Office database:

.\CreateMailboxDBs.ps1 -DBName "London_Office" -DBPath "x:\ExchangeDatabases\London" -LogFilePath "x:\ExchangeLogs\London"

When the script executes you will see information similar to the following screen shot. The script will also pause whilst it seeds the databases on the other servers.

When the script has completed its actions – you will see the following output from the script.

You can then open up the Exchange Administrative Centre and check that your databases correctly – see below.

Configuring SSL

Generating the Exchange Certificate

On either art-CASMBX-01 or 02 open am Exchange Management Shell Window and type in the following command, ensure that you include all the domains (SAN’s) that you would like registered on the certificate within the –DomainName parameter (separated by commas) – see below.

New-ExchangeCertificate -FriendlyName "artLab Certificate" -DomainName autodiscover.artTest.local,owa.artTest.local,mail.artTest.local -GenerateRequest -PrivateKeyExportable $true -KeySize 2048 -RequestFile "x:\DomainCSRRequest.csr"

This will generate a new Certificate Signing Request (CSR) that we can submit to the Active Directory Certificate Services component which is installed on art-DC-01. The command will output a CSR file to a location that you specify which will contain text similar to that in the example below.

If you then run the following command you can see that there is now a pending Certificate Request

Get-ExchangeCertificate | Where {$_.Status –eq “PendingRequest”} fl

Open Internet Explorer on your Exchange server and navigate to http://art-dc-01/certsrv (or the name that you gave you domain controller). From the screen that appears – click on the “Request a Certificate” link – see below.

On the next screen click on the “Advanced Certificate Request” link – see below

On the next screen – click on the “Submit a certificate request by using a base 64 encoded CMC or PKCS #10 file” – see below

Open the CSR file that you created using the New-ExchangeCertificate cmdlet – and copy and past its content in to the section on the next screen entitled “Base64 encoded certificate request (CMC or PKCS #10 or PKCS #7)” – ensure that the certificate template is set to “Web Server” and then click on the “Submit” button – see below.

You will be redirected to a screen where you can now download your certificate – click on the “Download Certificate” link – see below.

Save the Certificate file to a location on art-CASMBX-01 – see below:

Importing and enabling the Certificate

From within the Exchange management shell type in the commands below, ensure that you provide the path to your certificate file that you downloaded. Note that you will need to provide the thumbprint for the imported certificate when you use the Enable-ExchangeCertificate – bear in mind that the THUMBPRINT of the cert is likely to be different from that in my example. The commands below also enables the certificate for the web services (IIS).

Import-ExchangeCertificate -FileName X:\artTest.cer

Thumbprint Services Subject

98F1888F5CD7B4C227B9FEB6A321E5AE6249CD3C ....... CN=autodiscover.artTest.local

Enable-ExchangeCertificate 98F1888F5CD7B4C227B9FEB6A321E5AE6249CD3C –Services IIS

We now need to export this certificate from art-MBXCAS-01 to 02 – in order to do this type in the following Exchange Management Shell commands:

Verify the certificate thumbprint

Get-ExchangeCertificate

Thumbprint                                Services   Subject
  
----------                                --------   -------

  
98F1888F5CD7B4C227B9FEB6A321E5AE6249CD3C  ...W...    CN=autodiscover.artTest.local

  
6424884DC425680ABE842CBFA13E8FF590C94A90  ....S..    CN=Microsoft Exchange Server Auth Certificate

  
B265CDA2135D83E12453DCEA70C9BACDB698B05F  IP.WS..    CN=art-mbxcas-01

  
CB0DB4239F5D7E974B33F0E95EF5E01231183003  .......    CN=WMSvc-ART-MBXCAS-01

Export the Certificate

$export = Export-ExchangeCertificate 98F1888F5CD7B4C227B9FEB6A321E5AE6249CD3C -BinaryEncoded:$true -Password (Get-Credential).password

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

You will be prompted for a user name and password – enter in admin (not used) as the user name and select a password that will be used as the private key (you will need this when you import the certificate into art-MBXCAS-02).

Create the PFX file

Set-Content -Path x:\exportedCert.pfx -Value $export.FileData -Encoding byte

Import the Certificate

Remember that this time around, we are using the –Server parameter to stipulate that we want to allocate this exported cert on to art-MBXCAS-02.

Import-ExchangeCertificate -Server art-mbxcas02 -FileName X:\exportedCert.pfx -Password (Get-Credential).password

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

  
Credential

Thumbprint                                Services   Subject
  
----------                                --------   -------

  
98F1888F5CD7B4C227B9FEB6A321E5AE6249CD3C  .......    CN=autodiscover.artTest.local

You will be prompted to supply the password that you selected when you exported the certificate in order to complete the import operation.

Enable the services

Enable-ExchangeCertificate 98F1888F5CD7B4C227B9FEB6A321E5AE6249CD3C -Server art-mbxcas02 –Services IIS

Again, remember that the thumbprint will be different on your system – also remember that you need to stipulate the –Server parameter to make sure that you are working against art-MBXCAS-02.

Creating relevant DNS records

The certificate that you generated should have contained a number of other Domain Names (or subject alternative names) – for example in my LAB these were:

• OWA.artTest.local
• MAIL.artTest.local
• Autodiscover.artTest.local

It is important that these also appear within DNS within the LAB. In order to create these – logon to your LAB domain controller (art-DC-01) – and open a Powershell Command Prompt. Type in the following commands – substituting the IP addresses where appropriate to match that of your own subnets.

Import-Module DNSServer
Add-DnsServerResourceRecordA -Name "autodiscover" -ZoneName "artTest.local" -AllowUpdateAny -IPv4Address "172.31.253.108" -TimeToLive 01:00:00
Add-DnsServerResourceRecordA -Name "owa" -ZoneName "artTest.local" -AllowUpdateAny -IPv4Address "172.31.253.108" -TimeToLive 01:00:00
Add-DnsServerResourceRecordA -Name "mail" -ZoneName "artTest.local" -AllowUpdateAny -IPv4Address "172.31.253.108" -TimeToLive 01:00:00

Configuring Web Services in Exchange 2013

Like in previous versions of Exchange there are a number of internal URLS that need to be configured to ensure that services such as the EWS, Autodiscover and OWA work correctly.

One significant change is that there technically no longer the concept of –InternalURL / –ExternalURL on the autodiscover virtual directory. These are now handled via Service Connection Points (SCPs) in Active Directory and for the purposes of our LAB don’t need modification.

In Exchange 2013 there are a number of Virtual Directories that you change the URL settings on – therefore I have provided the following script to automate the process for our LAB.

NOTE: This script ONLY modifies the InternalURL namespaces – it will need modification if you wish to use external URLs. Furthermore it does not make modifications to the OAB Virtual Directory.

As with the previous script – you can copy and paste it from here – or download it from the link below.

<#
    Exchange 2013 LAB - Configure Web Based URLS

http://www.telnetport25.com

    Author: Andy Grogan
    Version: 0.1
    
    .Compatibility
    
    Windows Server 2012
    Powershell 3
    Exchange 2013
    Not Supported with any other versions of the software mentioned above.
    
    .Parameters
        None
    
    .Example
        .\ConfigureWebURLS.ps1
    
#>

$InternalDomainName = Get-ADDomain | select -expandProperty dnsRoot

Write-Host "Setting Domain Context: $InternalDomainName" -foregroundcolor Red

# Configure Client Access Server

Write-Host "Configuring CAS URLS" -foregroundcolor Cyan

$ClientAccessServer = Get-ClientAccessServer | select -expandProperty Identity
    
foreach($CAS in $ClientAccessServer){
    Set-ClientAccessServer –id $CAS –AutodiscoverServiceInternalUri "https://autodiscover.$InternalDomainName"
}

# Configure Active Sync

Write-Host "Configuring Active Sync URLS" -foregroundcolor Cyan

$aSyncDirs = Get-ActiveSyncVirtualDirectory | select -expandProperty Identity

foreach($aSyn in $aSyncDirs){

    Set-ActiveSyncVirtualDirectory -id $aSyn -internalURL "https://mail.$InternalDomainName/Microsoft-Server-ActiveSync"

}

# Exchange Control Panel

Write-Host "Configuring ECP URLS" -foregroundcolor Cyan

    $ecpVirDirs = Get-EcpVirtualDirectory | select -expandProperty Identity

foreach ($eVdir in $ecpVirDirs){
    Set-EcpVirtualDirectory –Identity $eVdir –InternalURL "https://owa.$InternalDomainName/ecp"
}

# Web Services

Write-Host "Configuring Web Services URLS" -foregroundcolor Cyan

    $webSvcVirDirs = Get-WebServicesVirtualDirectory | select -expandProperty Identity
foreach($webSvc in $webSvcVirDirs){
    
    Set-WebServicesVirtualDirectory –Identity $webSvc –InternalURL "https://mail.$InternalDomainName/EWS/Exchange.asmx"
    
}

# OWA

Write-Host "Configuring OWA URLS" -foregroundcolor Cyan
    $owaVdir = Get-OwaVirtualDirectory | select -expandProperty Identity
    
    foreach($oVDir in $owaVdir){
        Set-OwaVirtualDirectory –Identity $oVDir –InternalUrl "https://owa.$InternalDomainName/OWA"    
    }

# Powershell

Write-Host "Configuring Powershell URLS" -foregroundcolor Cyan
    $psVdirs = Get-PowerShellVirtualDirectory | select -expandProperty Identity

    foreach($psDir in $psVdirs){

    Set-PowerShellVirtualDirectory –Identity $psDir –InternalURL "https://mail.$InternalDomainName/powershell"
    
    }
Write-Host "Script has completed..." -foregroundColor Green

[ ConfigureWebURLS.ps1 – 2.4 KB ]

In order to run the script – open an Exchange Management Shell on either art-MBXCAS-01 or 02 and type in:

.\ConfigureWebURLS.ps1

The script will then execute and configure the relevant internalURLS for each service. You can then navigate to https://owa.artTest.local/owa and you should see that the certificate is trusted and everything functions as you would expect.

In the next part

In the final part of the series we will complete the following:

• Populate the lab with test users.
• Create Mailboxes
• Create Public Folders
• Create some distribution lists
• Discuss some options for implementing HA on the Client Access Servers for connectivity

Welcome to part 6 in my series of how you can build an Exchange 2013 LAB using Windows Server 2012. In the previous parts (should you wish to read them, refresh or catch up) can be found below:

Part 1

We established our domain design, covered how to provision the Domain Controller for the LAB in Hyper-V and then how to install Windows Server 2012 on the Domain Controller.

Part 2

We went through the process of installing Active Directory Domain Services on the LAB domain controller using PowerShell.

Part 3

We covered how you can install a very simple PKI infrastructure on the domain controller using Active Directory Certificate Services. These will be used in a later part to configure SSL for various parts of Exchange 2013.

Part 4

We covered how to use PowerShell to provision Exchange server VM’s in the lab, and went through the pre-requisite software installation.

Part 5

We covered the Directory, organisation and Exchange preparation – and then went on to install the relevant Exchange servers using the unattended setup feature.

In this part I would like to cover the steps to setup a Database Availability Group within the LAB. Now before we begin it is probably a good idea to cover a couple of concepts about DAG’s and how this configuration (sic. the LAB configuration) differs from what you might expect to place into production.

And now for Part 6:

Whistle stop tour of Database Availability Groups

Ok, I don’t intend to go into any large level of detail here about DAG architecture – I just want to cover enough to understand what we are implementing in our LAB and how this would differ in a production environment.

First off here is a definition from Microsoft about DAG’s which you can find, along with other interesting information here: http://technet.microsoft.com/en-us/library/dd979799(v=exchg.150).aspx

A database availability group (DAG) is the base component of the high availability and site resilience framework built into Microsoft Exchange Server 2013. A DAG is a group of up to 16 Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases.

A DAG is a boundary for mailbox database replication, database and server switchovers, failovers, and an internal component called Active Manager. Active Manager, which runs on every server in a DAG, manages switchovers and failovers.

Any server in a DAG can host a copy of a mailbox database from any other server in the DAG. When a server is added to a DAG, it works with the other servers in the DAG to provide automatic recovery from failures that affect mailbox databases, such as a disk failure or server failure.

With that basic understanding of DAG’s it is now important to get to grips with the concept of Quorum Models within DAGs.

Underpinning each DAG configuration is the Windows Failover Cluster Service. As some of you will be aware, failover clusters make use of the Quorum concept which basically means that that the correct  (and correct number of) members of a cluster (or DAG) are participate to ensure availability. This can mean all of the nodes in the cluster, or a majority of them (more on this later).

All clusters (or DAG’s) must have and maintain quorum – if not, all DAG operations will cease – and therefore cause all databases to dismount, rending the LAB (or production environment)offline.

DAGs that have an even number of members (e.g 2,4,6 etc.) will use failover clustering’s Node and File Share Majority, whereas DAGs with an odd amount of members (e.g 3,5,7 etc.) will use Node Majority.

In the case of Node and File Share there is an external “Witness Server” which is used to provide one DAG member with a weighted “vote” (e.g. the selected node gets two votes instead of one).

In the case of Node Majority – each member of the cluster (DAG) get a vote and will require the majority of members to be online and functional in order to maintain quorum. I have covered quorum models and majorities in the following article http://www.telnetport25.com/2011/12/its-a-majority-thing-dag-voting-explained-a-bit/.

You might be thinking, ok this is all well and good – but what does this have to do with our LAB?

Well, in our configuration we have provisioned 3 Exchange servers – two of which are multi-role (running CAS and MBX services) and the remaining being a mailbox server only.

This allows for us to build a DAG within our lab that will adopt the Node majority model (as well as build a supported environment – as Microsoft recommends a minimum of 3 database copies of each DB in a DAG ~ therefore a minimum of three members).

However, when creating a DAG you still need to specify a File Share witness server and location, even if you expect to have an odd number DAG membership. The reason for this is that if for some reason you change the number of members of the DAG to an even count – the specified witness will then come into play to maintain quorum.

This leads us onto the obvious – we (I) have not provisioned for a server within the LAB to act as the File share witness (I made this choice for this series based on conservation of resources and Windows activations).

Members of a DAG cannot also act as a FSW – it needs to be on a separate server – this leaves us within only one option ~ the Domain Controller to act as the FSW.

Now, using a Domain Controller as an FSW is NOT recommended in production for a number of reasons – but most pertinent of which are that such a configuration requires some messing around with some highly privileged group membership within AD that you really, really do not want to do – but can be excused in a LAB (most of the time – if you are planning on making your LAB web facing, provision a separate server for the FSW or combine it with something else in the same domain).

Specifically, in order for the process of assigning the FSW to a DC to work – the following needs to be configured:

• The domain controller needs to be a member of the “Exchange Trusted Administrators” group
• The “Exchange Trusted Administrators” group needs to be a member of the domains “BUILTIN\Administrators” group

I must stress – this is not the case in production, you do not need to change the membership of these groups (nor should you) if you are using a separate, non-domain controller as the FSW.

DAG Configuration from CSV File Script

In order to use the DAG creation script in our DAG environment – you should build the CSV file that contains our desired DAG settings.

To do this open up a text file and type in the following headings – each separated with a comma:

• DAGName
• WitServerName
• WitnessDir
• DAGIP

Underneath each of the headings you should provide a value (relevant to your environment) separated again by a comma – see the example below.

When you are done save the file as DagData.csv in a location where you intend to create the ConfigureDAG2013.ps1 file.

Below is the source code to the script – you have two options:

1. Copy and paste it to a blank ps1 file located on the art-MBXCAS-01 server in the LAB (if you have been following the naming conventions).
2. Download a copy of the script file from the downloads section next in this article.

<#
    Exchange 2013 LAB - Create DAG Script from CSV

http://www.telnetport25.com

    Author: Andy Grogan
    Version: 0.1
    
    .Compatibility
    
    Windows Server 2012
    Powershell 3
    Exchange 2013
    Not Supported with any other versions of the software mentioned above.
    
    .Parameters
        -CSVFile
    
    .Example
        .\ConfigureDAG2013.ps1 -CSVFile <Path and Name to CSV file>
    
    .CSV File Headings (all required)
        DAGName,WitServerName,WitnessDir,DAGIP
    .Notes
        DO NOT USE THIS SCRIPT AS IS IN PRODUCTION
        Ensure that you comment out the prep_Security function!
#>

[CmdletBinding()]
Param(
    [Parameter(Mandatory=$True)]
    [string]$CSVFile       
)

$DAGInfo = Import-Csv $CSVFile

function prep_Security{
    
    Write-Host "Prepping Security Permissions - Don't do this in PRODUCTION!" -Foregroundcolor Cyan
    
    # Add the domain controller to the Ex Trusted SS group
    # Not a good thing to do - only doing this as its a LAB
    
    Write-Host "Adding Domain Controller to Exchange Trusted Subsystem" -foregroundcolor Green
    
    $LABDomainDN = (Get-ADDomain).DistinguishedName
    $LABDC = (Get-ADComputer -Filter * -SearchBase "OU=Domain Controllers,$LABDomainDN").DistinguishedName
    Add-ADGroupMember "Exchange Trusted Subsystem" $LABDC
    
    # Add Ex Trusted SS to Builtin\Administrators
    
    Write-Host "Exchange Trusted Subsystem to Builtin\Administrators" -foregroundcolor Green
    
    Add-ADGroupMember "Administrators" "Exchange Trusted Subsystem"

}

function new_Dag{

    param(
    
    $DAGName,$WitServerName,$WitnessDir,$DAGIP
    
    )
    Write-Host "Creating the DAG" -foregroundColor Green
    New-DatabaseAvailabilityGroup -name $DAGName -WitnessServer $WitServerName -WitnessDirectory $WitnessDir -DatabaseAvailabilityGroupIPAddress $DAGIP
    
}

function add_Members{

    param(
        $DAGName,$Server
        
    )
    Write-Host "Adding DAG Member" $Server -ForeGroundColor Green
    Add-DatabaseAvailabilityGroupServer -id $DAGName -MailboxServer $Server

}

# Comment out prep_Security for Production Environments

prep_Security

new_Dag $DAGInfo.DAGName $DAGInfo.WitServerName $DAGInfo.WitnessDir $DAGInfo.DAGIP

$Members = Get-MailboxServer | Select -expandProperty Name

foreach($SVR in $Members){
    
    add_members $DAGInfo.DAGName $SVR

}

$DAGSummary = Get-DatabaseAvailabilityGroup | Select Name,DatabaseAvailabilityGroupIpAddresses,Servers
Write-Host $DAGSummary -foregroundcolor Cyan
Write-Host "Script Completed..."

The script performs the following actions:

1. Sets up the relevant permissions to allow for the domain controller to act as the FSW for the DAG.
2. Takes the data from the DAG configuration CSV file and parses it to the relevant functions in the script.
3. The relevant functions will: Create the DAG, Add the Mailbox Servers as members of the DAG.

When a member server is added to the DAG – the Add-DatabaseAvailabilityGroupServer cmdlet will automatically install the Failover Clustering Service on each node.

Download

You can download the above script and a sample CSV file from the links below

[Configure Exchange 2013 DAG Script – 2.4KB ]

[ Sample DAG Configuration CSV 0.9KB ]

Using the Script

On art-MBXCAS-01 open an Exchange Management Shell. Navigate to the location where you either created the script file, or downloaded it and type in:

.\ConfigureDAG2013.ps1 –CSVFile .\NameOfDAGCSVFile

If you downloaded the file you will need to ensure that the PowerShell execution policy is set to “RemoteSigned” – see here for further information.

When you hit the <Enter> key the script will begin the process of querying the CSV file and creating the DAG. All of the Servers within our LAB (as they are hold the Mailbox server role) will be added as members – see below.

When the script has completed you will be presented with a summary of the configuration. During execution you might see warning messages which suggest that access has been denied to the FSW – these can be ignored.

When the script has completed you can review the configuration via the Exchange Administrative Centre or from the Management Shell – see below:

Or in the EAC:

In the next part

In part 7 I will be covering the following:

• Creating our LAB Databases and adding them to our DAG
• Configuring Autodiscover, EWS, OWA and other IIS URI’s with the CA that we installed in Part 3

As a quick re-cap from what we have covered so far in this series:

Part 1

We established our domain design, covered how to provision the Domain Controller for the LAB in Hyper-V and then how to install Windows Server 2012 on the Domain Controller.

Part 2

We went through the process of installing Active Directory Domain Services on the LAB domain controller using PowerShell.

Part 3

We covered how you can install a very simple PKI infrastructure on the domain controller using Active Directory Certificate Services. These will be used in a later part to configure SSL for various parts of Exchange 2013.

Part 4

We covered how to use PowerShell to provision Exchange server VM’s in the lab, and went through the pre-requisite software installation.

In this part (5) of the series I will take you through the process of installing Exchange on the first Client Access and Mailbox Server art-MBXCAS-01 – this includes Active Directory and Organization preparation. I will then round off with explaining how you can then go onto complete the installation on the remaining servers.

Installing Exchange

Before you begin the setup process ensure that there are no pending reboots from any other installations (for example Windows Update or Role / Feature installations). Failure to do so may result in the following error message being presented within Exchange Setup.

Performing Microsoft Exchange Server Prerequisite Check
Prerequisite Analysis - FAILED
There is a pending reboot from a previous installation of a Windows Server role or feature. Please restart the computer and then run Setup again.
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.PendingRebootWindowsComponents.aspx
The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.

Required Permissions

Although this is a lab, and if you have been following this guide closely you should already have the required permissions to install Exchange. However for the sake of completeness make sure that the account that you are logged on with has the following permissions:

• Schema Admins
• Enterprise Admins

Open an elevated command prompt and navigate to the folder (or drive) where you have the Exchange 2013 media located. Then type in the following command line:

setup.exe/prepareAD /OrganizationName:artTest /IAcceptExchangeServerLicenseTerms

This will begin the process of Organisational Preparation. Specifically by using the /prepareAD switch the following is completed (summarised from TechNet http://technet.microsoft.com/en-us/library/bb125224.aspx):

• If the Microsoft Exchange container doesn’t exist, this command creates it under CN=Services,CN=Configuration,DC=<root domain>.
• Verifies that the schema has been updated and that the organization is up to date by checking the objectVersion property in Active Directory. The objectVersion property is in the CN=<your organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container. The objectVersion value for Exchange 2013 is 15449.
• Sets the msExchProductId of the Exchange organization object to 15.00.0516.032. The msExchProductId property is in the CN=<your organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container.
• If the Exchange Organisation containers don’t exist they are created.
• If it doesn’t exist, creates the default Accepted Domains entry, based on the forest root namespace, under CN=Transport Settings,CN=<Organization Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain>.
• Assigns specific permissions throughout the configuration partition.
• Imports the Rights.ldf file. This adds the extended rights required for Exchange to install into Active Directory.
• Creates the Microsoft Exchange Security Groups organizational unit (OU) in the root domain of the forest and assigns specific permissions on this OU.
• Creates the relevant management groups within the Microsoft Exchange Security Groups OU
• Adds the new universal security groups (USGs) that are within the Microsoft Exchange Security Groups OU to the otherWellKnownObjects attribute stored on the CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain> container.
• Creates the Unified Messaging Voice Originator contact in the Microsoft Exchange System Objects container of the root domain.
• Prepares the local domain for Exchange 2013.

When the preparation has been completed you will be returned to the administrative command prompt. If you have provisioned more than one domain controller in your LAB – you should wait for Active Directory replication to complete (as the setup process creates a number of schema changes and objects). You don’t have to – but a reboot of the Exchange Server can also be useful at this point.

If you have rebooted, logon to your first Exchange server and open up an Administrative command prompt and navigate back to the location of the Exchange 2013 installation media. This time we are going to install the relevant roles on the Server as per the design that we earmarked in article 1.

Here we are going to use Setup.exe with a number of command line switches (unattended mode):

• /Mode:Install – sets the setup program to run in install mode (perhaps that was obvious ~ the other option is uninstall)
• /Role:ClientAccess,Mailbox – the two roles that we want to host on the server
• /MdbName:GeneralStore – this allows for us to specify a name for the default store that is created during setup, if we don’t include this Exchange will create a generic named store
• /DbFilePath:<PathToEdbFile>\General.edb – places the default store in the a different location to the default which is located under the Exchange installation path
• /LogFolderPath:<PathToLogs> – places the transaction logs in a different location to the default which is located under the Exchange installation path
• /IAcceptExchangeServerLicensingTerms – does what it says on the tin!

So given the above, our (my) command line looks like the following:

Setup.exe /mode:Install /role:ClientAccess,Mailbox /MdbName:GeneralStore /DbFilePath:X:\ExchangeDBs\General\GeneralStore.edb /LogFolderPath:X:\ExchangeLogs\General /IAcceptExchangeServerLicenseTerms

Once you have hit the <Enter> key – Exchange setup will then go away and complete the installation process:

Once Exchange setup has finished, you will be presented with output that should look similar to that below:

It is always a good idea to reboot the server at this point to completely finalise the setup.

Checking your Exchange Installation

When your Exchange Server has rebooted open Internet Explorer on the server and type in the following address:

https://localhost/ecp 

You should then be presented with the Exchange Administrative Centre logon screen:

Using the administrator account – provide the logon details on the above screen which should then take you into the Admin Interface. Navigate to Servers (from the option on the left hand side of the screen) and check to see if your server appears as expected. I also recommend that you have a browse around to familiarise yourself wit a number of other features that are available within the interface.

Configuring the Servers Secondary Interface

The scripts that we used to provision the Exchange Servers will have created two network adapters. One of the adapters is used for Public Network communications (Clients etc.) and the other is used as the replication interface (this is marked on the diagram and the 10.0.0.x address into the private V-Switch. I recommend that you rename the interfaces on your LAB servers so that their purposes are marked.

Assign the replication interface (on art-MBXCAS-01) the relevant private IP address range that you have assigned within your own LAB environment. In mine I have used the following:

• IP Address = 10.0.0.1
• Mask = 255.255.252.0

You should also configure you settings on this replication interface to match the following Advanced configuration items on the following tabs:

DNS Tab

WINS

Installing Exchange on the remaining Servers

You we are now in a position to install Exchange on the remaining servers within the infrastructure – at this point our LAB should look like the following.

We should have the following servers left to install Exchange 2013 on:

• art-MBXCAS-02
• art-MBX-01

art-MBXCAS-02

You should follow the exact same process that has been provided in this article, with the following changes:

• You do not need to run the organisation preparation command:

setup.exe/prepareAD /OrganizationName:artTest /IAcceptExchangeServerLicenseTerms

• You should only run the install roles command of:

Setup.exe /mode:Install /role:ClientAccess,Mailbox /MdbName:GeneralStore02 /DbFilePath:X:\ExchangeDBs\General02\GeneralStore02.edb /LogFolderPath:X:\ExchangeLogs\General02 /IAcceptExchangeServerLicenseTerms

• When you configure the replication interface on art-MBXCAS-02 you should provide the next available address in your private range, for example in my LAB this is:
  • 10.0.0.2

art-MBX-01

Again, you should follow the exact same processes that have been described in this article – only with the following changes:

• You do not need to run the organisation preparation command:

setup.exe/prepareAD /OrganizationName:artTest /IAcceptExchangeServerLicenseTerms

• You should only run the install roles command of:

Setup.exe /mode:Install /role:Mailbox /MdbName:GeneralStore03 /DbFilePath:X:\ExchangeDBs\General03\GeneralStore03.edb /LogFolderPath:X:\ExchangeLogs\General03 /IAcceptExchangeServerLicenseTerms

This will ensure that only the Mailbox role is installed.

When you configure the replication interface on art-MBX-01 you should provide the next available address in your private range, for example in my LAB this is:

• 10.0.0.3

In the next part

I will be covering the following aspects of the Exchange configuration:

• Configuring the Database Availability Groups for the LAB.

Recently I released version 4.0 of the OOOCTA, which was a complete re-write of version 3.5 which some years ago (which is now no longer supported). I have had some really great feedback from readers of the site which I have decided to roll up into a .1 incremental release from version 4.0.

Specific enhancements in version 4.1 are:

• BUG FIX: Fixed problem with an Exception being thrown when either the Internal or External Message contains either a ‘ or "
• New Feature: Added in the ability to configure the target audience for external replies (All, Contacts or None)
• New Feature: Added in an operational status which reports the result of a configuration change.

I have also updated the installation and users guide to reflect the upgrade process from version 4.0 to 4.1 and the new functionality.

Version 4.0 is still available for download from the original article, however I will be retiring it in the next few weeks.

Pre-Requisites

The following are the pre-requisites for the OOOCTA version 4.1.

• Windows Server 2008 R2.
• IIS 7.0.
• .NET Framework 3.5 or above.
• Exchange 2010 Service Pack 2 or above.
• Exchange 2010 Management Tools installed on the primary OOOCTA server.
• The OOOCTA Application Service Account will require Exchange Organization Management rights, you will also need the account that you use to install the software has these rights as well.

It is recommended that you install the OOOCTA on a Client Access Server within your environment. Whereas this is not essential to the operation of the tool – it makes the setup easier.

Download

You can download both the OOOCTA v 4.0 and the Installation and Users guide from the following locations.

[ OOOCTA v 4.1 for Exchange 2010 – 196KB ]

[ OOOCTA v 4.1 Installation and Users Guide – 1.1 MB ]

I hope that you enjoy OOOCTA 4.1, and of course value your feedback.

A reader of my blog contacted me the other day with the following question:

I am a contractor at my company which is being broken up because of investment developments. I need to do the following.

Company has about 4200 users total

About 1300 have gone to another company almost all of these have normal mailboxes in our existing organisation

• They want to create mail enabled contacts for these users (that is why I downloaded your Contact Master Tool as it looks like it will work great for that
• In their mailboxes they want to check the forward to also put in the forward to address

I think I am going to have to run Contact Master to do the contacts and run another script to do the “Forward Items” – is my thinking correct?

Is there a PowerShell script that you could help me with to take care of the checkbox and forward address?.

The good news is that this is very easy using PowerShell and a simple CSV file.

Structure of the CSV file

In order to use the script within this post you will need to build a CSV file that contains the following headers:

• Mailbox – This is the alias of the Mailbox on your Exchange Server that you want to configure the forwarder for.
• Forwarder – This is the alias of the contact that you wish to forward the mail onto.

And then add in the relevant Mailbox and Contact aliases – see below

The script

The following script can be pasted into a new PS1 file on your Exchange Server.

[CmdletBinding()]
Param(
    [Parameter(Mandatory=$True)]
    [string]$CSVFile,[Parameter(Mandatory=$True)]
       [boolean]$DeliverToMailboxAndForward
)

$FileName = $CSVFile
$UserInformation = Import-Csv $FileName

Foreach ($User in $UserInformation){

    $Mailbox = $User.Mailbox
    $Forwarder = $User.Forwarder

    Set-Mailbox -Identity $Mailbox -ForwardingAddress $Forwarder -DeliverToMailboxAndForward $DeliverToMailboxAndForward

}
Write-Host "Script Completed..." -ForegroundColor Green

Running the script

The script requires two parameters which are as follows:

• CSVFile – This is the path to the CSV file that contains the mappings.
• DeliverToMailboxAndForward – The value should either be $True or $False – if you select $True then messages will be delivered to the local mailbox and to the forwarder, if you select $false if you only wish for the mails to be sent onwards.

You can run the script by using the following format:

.\<name that you have given the script> –CSVFile <path to CSV> –DeliverToMailboxAndForward

If you need assistance – you can refer to the following post which explains how you can run PowerShell script files: http://www.telnetport25.com/2012/02/quick-tip-running-exchange-based-powershell-script-files-from-the-command-line-or-a-batch-file/

When the script has executed you should see the following output:

Hope that someone finds this useful.

A long time ago (in a Galaxy far, far away) I released a tool for Exchange 2007 called the OOOCTA. In essence the OOOCTA allowed for administrators to delegate (via a web interface) the configuration and reporting of Out of Office.

To be honest, this tool was a little … clunky. Don’t get me wrong – it did work, but at the same time suffered from a number of bugs that I struggled to eliminate from the code. Some people downloaded it and tried to use it with mixed fortunes – but the long and short of it was it was a victim of its own complexity.

I did try and support as many people as I could – but one of the odd things that I found was that despite it being a pretty standard install, no two environments seemed to exhibit the same problems – there were some that never had an issue (and are still using it today), whilst others had to abandon it.

You see, in Exchange 2007 there is no direct way to set, modify or report on a users Out of Office settings. The OOOCTA (version 3.5) used the Exchange EWS API to set OOF configurations via an agent service which ran on one of the Exchange servers in an organisation. This agent would take input from a SQL database (which contained the users which the admin wish to set the OOF for) – assigned permissions to the mailbox, and using the EWS API – change the OOF configuration and then remove the permissions. Sounds simple enough – but in practice, it was a flawed design and suffered from a number of reliability problems.

The root issue was assigning permissions to the Mailbox to allow for the OOF to be modified. In Exchange 2007 you had to be the mailbox owner (or have full permissions) in order for the EWS code logic to work – I wrote more about this here: http://www.telnetport25.com/2012/01/exchange-2010-out-of-office-fun-with-set-mailboxautoreplyconfiguration/.

You see, by changing the permissions on the mailbox (which the OOOCTA Command Processor Service did in version 3.5) – you had to wait for the permissions to take effect (if you had more than one than domain controller). This meant that it could be difficult for the OOOCTA to set the OOF on the first service pass (the service queried the OOOCTA SQL Database at a predefined interval). Sometimes and for reasons that I still don’t fully understand – it would miss some entries in the database completely, resulting in having to pour over the OOOCTA logs, and sometimes completely clear the database and start again.

Since the release of OOOCTA 3.5; I have been thinking long and hard about to future of OOOCTA being supported on Exchange 2007 – and I have decided to drop the tool for that version of Exchange.

There are a few reasons for this, but the main one being that with the release of Exchange 2013 – Exchange 2007 (whilst stull supported by Microsoft) is two clear versions down on the current release.

Furthermore fast forwarding to Exchange 2010 Service Pack 1 and Microsoft introduced two new cmdlets:

• Get-MailboxAutoReplyConfiguration
• Set-MailboxAutoReplyConfiguration

Which can be executed in the context of RBAC role – meaning that we can natively change the OOF settings on a mailbox without having to install the EWS or modify mailbox permissions.

Given the above, I would like to present to you OOOCTA – Version 4.0 for Exchange 2010, Service Pack 1 and above.

Why OOOCTA v4.0?

The Out of Office function is a very useful tool for customers working within organizations to let people know their whereabouts. However people do forget at times to set their Out of Office before they leave, which can result in delays in getting responses to queries from people who mail a person who is out of the office for a prolonged period of time – as they do not know that they perhaps should be speaking to someone else.

It is common for managers to call ICT Service Desks or HR departments asking for someone’s Out of Office to be configured. This tool allows for this to be delegated through a centralized and simple management interface.

OOOCTA version 4.0 is a complete re-write of the original tool. I have removed both the Windows Service and SQL requirements and added in the ability to configure the OOF’s in real time. I have simplified the install and user interface and improved the error handling.

The OOOCTA is based upon the same design principals as the recently released DLRT -

• Free
• Simple
• Easy to install
• Easy to troubleshoot
• Easy to Service

The OOOCTA v4 and the DLRT are also compatible with devices such as IPads and IPhones, which opens the possibility of configuring Out of Office on the move.

Reporting

Setting

Pre-Requisites

The following are the pre-requisites for the OOOCTA.

• Windows Server 2008 R2.
• IIS 7.0.
• .NET Framework 3.5 or above.
• Exchange 2010 Service Pack 2 or above.
• Exchange 2010 Management Tools installed on the primary OOOCTA server.
• The OOOCTA Application Service Account will require Exchange Organization Management rights, you will also need the account that you use to install the software has these rights as well.

It is recommended that you install the OOOCTA on a Client Access Server within your environment. Whereas this is not essential to the operation of the tool – it makes the setup easier.

Download

You can download both the OOOCTA v 4.0 and the Installation and Users guide from the following locations.

[ OOOCTA v 4.0 for Exchange 2010 – 196KB ]

[ OOOCTA v 4.0 Installation and Users Guide – 1.1 MB ]

I hope that you enjoy OOOCTA 4.0, and of course value your feedback.

So where were we?

Ah, yes – in the previous three parts of this series we have covered:

• The conceptual schematic of what our test lab domain will look like.
• Established the specifications for each of the virtual machines that we would be using in the Lab.
• How to provision the Domain Controller for the LAB in on Hyper-V server on Windows Server 2012.
• Built the Windows Server 2012 O/S for the domain controller.
• Installed Active Directory on the Domain Controller using a Powershell Script.
• Installed Active Directory Certificate Services on the domain controller.

If you would like to review those parts you can find them at the links below:

• Part 1
• Part 2
• Part 3

In this the fourth part of the Series I will take you through the provisioning of your Exchange Servers in Hyper-V, summarising the install of Windows Server 2012 Data Centre (as we have covered the step by step install of Windows 2012 in the first part), and finally installing the prerequisites for Exchange 2013 on Windows Servers 2012.

Provisioning your Exchange Servers

In part one of the series I took you through manually using the Hyper-V manager to provision the domain controller. In this part I would like to show you how you can use the Hyper-V module in Powershell to query settings in a CSV file and create your Virtual Machines using a very simple PowerShell script.

The script and CSV file

The following is the simple script that I have written which takes input from a CSV file (more details on this later) and creates the Virtual Machines as per the configuration data from the source file.

<#

    Simple Powershell Script to Provision Hyper-V Guests

    Version 0.1

    Author: Andy Grogan

    http://www.telnetport25.com

    Usage <scriptName.ps1> -csvFile

#>

Import-Module Hyper-V

Param(

    [parameter(Mandatory=$true)]

    [alias("CSV")]

    $CSVFile)

$VMData = Import-CSV $CSVFile

foreach($VMDef in $VMData){

    $VMName = $VMDef.VMName

    $VMPath = $VMDef.VMPath

    $VHDPathName = $VMDef.VHDPathName

    $VHDSize = $VMDef.VHDSize

    $VMMem = $VMDef.VMMemory

    $VSwitch = $VMDef.Vswitch

    $ProcCount = $VMDef.ProcessorCount

    $ISO = $VMDef.OSISOPath

    if(!(Test-Path $VMPath)){

        New-Item $VMPath -Type Directory

    }    

    New-VM $VMName -Path $VMPath

    New-VHD -Path $VHDPathName -SizeBytes $VHDSize

    Add-VMHardDiskDrive -VMName $VMName -Path $VHDPathName -ControllerNumber 0

    Set-VMMemory -VMName $VMName -DynamicMemoryEnabled $True

    Set-VMMemory -VMName $VMName -MinimumBytes $VMMem -MaximumBytes $VMMem -StartupBytes $VMMem

    Add-VMNetworkAdapter -VMName $VMName -SwitchName $VSwitch

    Set-VM $VMName -ProcessorCount $ProcCount

    Add-VMDvdDrive -VMName $VMName –Path $ISO

}

Write-Host "Script Completed" -ForeGroundColor Green

The CSV file should contain the following column headings:

• VMName – Name of the Virtual Machine.
• VMPath – Physical path on your Server where the Virtual Machine configuration will live.
• VHDPathName – Physical path and file name of the primary system disk for your VM.
• VHDSize – Size of the system disk, this is represented in Bytes – therefore 100GB is 107374182400 bytes.
• ProcessorCount – The number of vCPU’s assigned to the Virtual Machine.
• VMMemory – The amount of RAM assigned to the Virtual Machine – this is in Bytes, therefore 5GB is 5368709120 in bytes.
• VSwitch – The name of the VSwitch that you wish the primary interface to use – in my lab this is called RIO_PUBLIC_VSWITCH.
• OSISOPath – The path on your Server to the Windows 2012 installation ISO.

Download

You can download a copy of the script above, and a sample CSV file for reference from the links below.

[ Hyper-V Provisioning Script – 1.1KB ]

[ Sample Source CSV File – 1.0 KB ]

Running the Script

Like with all the scripts that have been provided in this series – you need to ensure that before you try to run them – you have the correct execution policy configured (RemoteSigned). This is covered in the following post: http://www.telnetport25.com/2012/02/quick-tip-running-exchange-based-powershell-script-files-from-the-command-line-or-a-batch-file/

Copy the script and your CSV file to a location on your Hyper-V server, open a Powershell command prompt and use the following command line:

.\provVM.ps1 –CSVFile <path and name of CSV file>

The script will then go away and provision your machines.

If you then review the Hyper-V manager – you will see your new VM are now present:

If you check the properties of any one of the VMs you will see that they have been configured as per the settings in the CSV file.

You are now in a position to Power the VM’s on and being the process of installing Windows Server 2012 Data Centre.

Installing Windows 2012 Data Centre Edition

In the first part of this series; I did a detailed overview of installing Windows Server 2012 – therefore I will not be covering that again. Where you should pick the configuration up again in this post is after you have renamed the computer, configured the relevant IP settings and joined the machine to the art-test domain and installed relevant Windows Updates..

The first machine that we will build will be art-mbxcas-01 – which will be our first Mailbox / CAS and HT server.

What I will cover here is installing both the Operating System Pre-Requisites and supporting components required for a successful installation of Exchange 2013 on Windows Server 2012.

Required Operating System Components

On your Exchange Server – open a Powershell command prompt then enter in:

Import-Module ServerManager

Then enter in:

Add-WindowsFeature RSAT-ADDS

Then copy and paste the following code:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

You will then need to restart the computer – you can do this by typing:

Restart-Computer

Within the Powershell command window.

Required Supporting Software

In order to successfully install Exchange Server on the VM – you will need to install some supporting software which is required in order for it to function correctly.

You will need to download each of the following to a location on your Exchange VM:

1. Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
2. Microsoft Office 2010 Filter Pack 64 bit
3. Microsoft Office 2010 Filter Pack SP1 64 bit

You will then need to install them.

Microsoft Unified Communications Managed API 4.0, Core Runtime x64

As per Microsoft:

Unified Communications Managed API (UCMA) 4.0 is a managed-code platform that developers use to build applications that provide access to and control over Microsoft Enhanced Presence information, instant messaging, telephone and video calls, and audio/video conferencing.

Double click on the Setup installer for the MUCM API which will begin by showing you the following introduction screen.

You will then be presented with the following welcome screen which explains the actions that the installer intends to perform on your server. When you are ready click on the “Next” button.

Accept the licensing agreement by checking the “I have read and accept the license terms” then click on the “Install” button.

The setup process will then install the required components on your server.

Set will then complete – click on the “Finish” button.

Installing the Microsoft Office Filter Pack with Service Pack 1

As per Microsoft:

The Microsoft Filter Pack is a single point-of-distribution for Office IFilters. IFilters are components that allow search services to index content of specific file types, letting you search for content in those files. They are intended for use with Microsoft Search Services (Sharepoint, SQL, Exchange, Windows Search).

Install this product if you want to search for content in the file types listed below.

The Filter Pack includes:

Legacy Office Filter (97-2003; .doc, .ppt, .xls)

Metro Office Filter (2007; .docx, .pptx, .xlsx)

Zip Filter

OneNote filter

Visio Filter

Publisher Filter

Open Document Format Filter

Double click on the Microsoft Office Filter pack installer – you will be presented with the following welcome screen, when you are ready click on the “Next” button.

Accept the licensing agreement by checking the “I accept the terms in the licensing agreement” check box. When you are done click on the “Next” button.

The setup process will then install the required files on your Exchange Server.

When setup is completed – you will be presented with the following dialog box – click on the “OK” button to finish.

You will then need to install Service Pack 1 for the Microsoft Office filter pack. Double click on the Service Pack 1 setup file. You will then be presented with the introduction screen – click on the “Continue” button when ready.

Setup of Service Pack 1 for the Office 2.0 filter packs is very quick – when it has been completed you will be presented with the following dialog box – click on the “OK” button when setup has completed.

And then Repeat

You will now need to repeat the above setups on the remaining two servers:

• art-mbxcas-02
• art-mbx-01

In the next part

In the next part of the series I will cover:

• Preparing the Active Directory Schema and Domain.
• Installing Exchange 2013 on your provisioned Virtual Machines.

Last week I released version 2.0 of the DLRT for Exchange 2010. This week I am pleased to release a version which is compatible with Exchange 2013 which can be installed on Exchange 2013 servers.

Why two versions?

Normally I like to try and maintain a single code base for my tools across different versions of Exchange (e.g. if I write something for Exchange 2010 – I would like the same installer to function on Exchange 2013 if the purpose of the tool covers functionality in the target versions of Exchange).

However there are some very subtle differences between how cmdlets common to both Exchange 2010 and 2013 return values. These differences are not so obvious that you would notice them day to day – but – from a C# and Automation RunSpace perspective they require some slightly different code logic when returning Distribution Lists and their members to the DLRT Interface.

Furthermore; the Exchange 2013 Powershell management snap-in (which the DLRT integrates with) in compiled for .NET 4.5 – whereas the DLRT version for Exchange 2010 is compiled in .NET 3.5.

I could of course compile both versions of the code for 4.5 – but that would not get around the formatting differences between 2010 and 2013 cmdlets, and not everyone has .NET 4.5 installed on the 2010 servers (and they may not wish to).

Download

You can download the Exchange 2013 version of the DLRT from the link below – please note that this version will not function correctly when installed on an Exchange 2010 server.

The installation and setup is the same between the two Exchange versions with the only difference being the requirement for .Net 4.5.

  [ Distribution List Reporting Tool – Version 2.0 - Exchange 2013 – 190KB ]

[ DLRT Installation and Users Guide – 1.3MB ]

NOTE: If you would like to install the DLRT on Exchange 2013 – please use the version that has been posted here: http://www.telnetport25.com/2013/02/released-version-2-0-of-the-dlrt-for-exchange-2013/

A couple of weeks ago I released Version 1.0 of the Exchange Distribution List Reporting tool. Since then there have been a couple of updates to the original 1.0 code (versions 1.1 and 1.2) – however today I would like to present version 2.0 of the code.

I have been working on the DLRT for some months – therefore I have had a few code bases in development – and the changes in this release represent an amalgamation of all the development code that I have on my servers.

For information on the change history please see the information the change log below:

Version 1.0

• Initial release

Version 1.1

• Added in handling for environments where there are no distribution lists
• Added in handling for environments where there is only one distribution list
• Added in handling for lists that contain either no or only a single membership entry
• Added in an event debugging information field at the bottom of the main page

Version 1.2

• Added in handling for lists that contain spaces within their names
• Modified the version number on the logo to 1.2
• Added a “sort” button for the lists on the main page – this sorts the names Alphabetically

Version 2.0

• Modified Member list rendering engine from a list control to GridView when querying a single list
• Added in bulk reporting on all lists which contain members with new GridView renderer
• Added in bulk reporting on lists that contain no members with new GridView renderer
• Added in support for Distribution lists which have members in multiple domains
• Redesigned user interface
• Added in the ability to export list membership to a CSV file
• Bug Fix: Fixed the incorrect reporting of lists that contain a single nested Distribution Group
• Improved error and report handling than that in version 1.2

Download

The original code contained within the version 1.0 release article has now been replaced with Version 2.0. The installation and upgrade process between the two versions is the same (e.g. run the setup executable and install over the top) – the IIS and Active Directory configuration remain the same.

I have also included a full Installation and Users Guide within this download section.

  [ Distribution List Reporting Tool – Version 2.0 – 190KB ]

[ DLRT Installation and Users Guide – 1.3MB ]

Installation and Users Guide

Please see the PDF download in the download section.

Screenshots – Version 2.0

As a quick preview – I have included some screen grabs of the tool below.

Landing screen:

Populated Lists:

I hope that you enjoy the DLRT tool as much as I have enjoyed writing it – and of course that you find it useful.

In the previous two parts of this series I took you through building a Windows 2012 server on Hyper-V Server and then in the second part took you through the process of installing Active Directory Domain Services.

For reference these two posts are here and here.

In this part of the series I would like to take you through the process of installing and configuring Microsoft Active Directory Certificate Services on your domain controller. By then end of this article; our test lab will be one fourth complete – and looks like the following schematic:

You might be thinking – Andy, why are we installing this? Well the answer is simple: in our end Exchange 2013 test lab we are going want some SSL certificates generated for the OWA and Autodiscover services, rather than the self signed ones that are assigned after Exchange setup. Within the domain environment that we create; any SSL certificates that are generated from the Enterprise Root CA will be automatically trusted by the Exchange Servers and clients within that domain.

This means that we can generate as many certificates with as many Subject Alternative Names (SAN’s) as we like, without having to invest in any commercial certificates. If you should wish to install commercial certificates, you can skip this part and move onto part 4 when it is released.

Installing the Enterprise Root CAS

Rather than screenshot the entire process of configuring Active Directory Certificate Services – I thought that it would be easier to put together a quick video overview which is located below. Follow the steps outlined in the video overview customising them where needed to suit your own needs.

Within the video there is a Powershell script which is used to install the Certificate Service binaries – this is located here for download:

[ Install Active Directory Certificate Services Script – 1.1 KB ]

If you intend to use this script – you will need to follow the guide that I posted here which explains how you can execute PS1 files from the Internet by modifying PowerShell’s execution policy.

In the next part

I will cover the build of you Exchange 2013 Servers on Windows 2012 and explain the various prerequisites that you will need for a successful install.

In the previous part of this series (Part 1) I took you through to the point where you now have a basic Hyper-V guest which can be used as the domain controller for your Exchange 2013 Test Lab. In this part I would like to take you through how you can install Active Directory on that guest machine.

Now it is important to note that the process of installing AD on Windows Server 2012 is very different to previous versions of Windows. In versions of Windows from 2000 through to 2008R2 it was as simple as dropping to a command line and typing “DCPROMO” – but in Windows 2012 DCPROMO has been depreciated. You can type it in – but you will be told to use the Server Manager to perform an install of Active Directory Domain Services.

You can use the Server Manager to install Active Directory (but where is the fun in that?) – so, you guessed it – you can also use PowerShell.

So for the purposes of this article in the series I decided to write an Powershell automation script for the installation of Active Directory on the domain controller in our LAB.

As I said you can use the GUI – but I personally found that Powershell was quicker and less cumbersome.

Active Directory Installation Script

You can download the script from the link provided in the Download section below – or copy and paste it to your Guest Machine from the Script section.

Remember that this script is only designed for the following scenarios:

• Creating a new forest
• Creating a new domain
• Promoting your VM to a domain controller

It should not be used to add a domain controller to an existing forest / domain.

The script performs the following actions:

• Imports the ServerManager Modules (to allow for the add-WindowsFeature cmdlet to function)
• Installs the AD-DOMAIN-SERVICES role and the management tools
• Imports the ADDSDeployment module to allow for the configuration of Active Directory Services (after they have been installed)
• Defines a function that uses the Install-ADDSForest cmdlet which accepts the following parameters:
  • Directory Database Path
  • Directory Log Path
  • Directory SysVol Path
  • The AD Domain Name
  • The NetBIOS domain Name
• Gets the above values from the user
• Creates the Database, Log File and SysVol folder structure
• Installs Active Directory Services

If you examine the script you will see a number of other parameters that are used in conjunction with the Install-ADDSForest cmdlet – these are as follows:

• -DomainMode – this configures the Domain Functional Mode that the first domain (that the script creates) is configured to work under. The script configures this to be “Win2012”.
• -ForestMode – This configures the Forest Functional Level for the test LAB – the script sets this to be “Win2012”.
• -CreateDnsDelegation – (as per Microsoft) Indicates whether to create a DNS delegation that references the new DNS server that you are installing along with the domain controller. Valid for Active Directory-integrated DNS only. The default is computed automatically based on the environment. The script sets this to false.
• -NoRebootonCompletion – Instruct the Install-ADDSForest cmdlet to either reboot or not reboot automatically – the script has this set to $true, which means that you will need to reboot manually after completion.

Download

[ Install Directory Services Windows 2012 PS1 – 1.2KB ]

Script (for copy and paste)

<# 

    Author: A.Grogan

    http://www.telnetport25.com

    Version 0.1

#>

Import-Module ServerManager

Write-Host "*******************************************************"

Write-Host "*"

Write-Host "* Windows 2012 - Prepare Active Directory Script"

Write-Host "* For Windows 2012 Servers Only"

Write-Host "* Version 0.1"

Write-Host "* Will prepare the first Forest, Domain and Domain Controller"

Write-Host "* on Windows Server 2012"

Write-Host "*******************************************************"

Write-Host ""

Write-Host "Installing Required Windows Feature" -ForegroundColor Cyan

Write-Host ""

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Import-Module ADDSDeployment

function inst_AD{

    param($DatabasePath,$LogPath,$SysVolPath,$DomainName,$DomainNETBIOS)

    Install-ADDSForest -DomainMode Win2012 -ForestMode Win2012 -DomainNetbiosName $DomainNETBIOS -CreateDnsDelegation:$false -DatabasePath "$DatabasePath" -DomainName "$DomainName" -InstallDns:$true -LogPath "$LogPath" -NoRebootOnCompletion:$true -SysvolPath "$SysVolPath"

}

Write-Host "Getting AD Information - please answer the following questions" -ForegroundColor White

$DName = Read-Host "Please provide domain name for you AD Installation"

$NetB = Read-Host "Please provide the NETBIOS name for this domain"

$DBPath = Read-Host "Please provide a path for the Directory Database"

$LPath = Read-Host "Please provide a path for the Directory Logs"

$SVol = Read-Host "Please provide a path for the SysVol folder"

Write-Host ""

Write-Host "Creating Directories" -ForegroundColor Green

New-Item $DBPath -ItemType Directory -Force

New-Item $LPath -ItemType Directory -Force

New-Item $SVol -ItemType Directory -Force

Write-Host ""

inst_AD $DBPath $LPath $SVol $DName $NetB

Installing Active Directory on your Windows 2012 Domain Controller

In order to install Active Directory on the LAB domain controller – I downloaded the above script to my VM guest (well actually I wrote it on the Domain Controller; but you get what I mean).

Before you use the script in your environments you will need to ensure that your server’s Powershell execution policy is set to “RemoteSigned” – see the following article that I posted here for further information.

Then open a Powershell console window and navigate to the location where the script is located on your VM, and type the following:

.\instADWindows2012.ps1

The script will then execute – firstly it will install the Active Directory Domain Services role and management tools and then it will prompt you for the DNS domain name for your AD domain. In my Lab I have used “artTest.local”

The script will then prompt you further for the following information:

• NetBIOSName for the domain
• Location of the Directory database (this MUST NOT have a trailing slash at the end)
• Location of the Directory Logs (this MUST NOT have a trailing slash at the end)
• Location of the Directory SysVOL folder (this MUST NOT have a trailing slash at the end)

You will be prompted for the “SafeModeAdministratorPassword” – this is the equivalent of the traditional “Directory Services Restore Mode” Password of old but can also be used when starting the Domain Controller in “Safe Mode”.

You will then be asked to confirm that you wish for the installation process to configure your server as a domain controller – confirm with “Y” to continue.

The Install-ADDSForest cmdlet will then continue with the installation of the Director Services on your domain controller.

During the configuration you may see a number of warnings similar to those in the example below – these can be safely ignored as this is a test Lab that will only consist of Windows 2012 machines and no other DNS servers.

When the process has completed you will be presented with a short summary of the actions completed. You will need to reboot your VM.

To reboot the machine – type:

Restart-Computer

At the management shell prompt.

In the next part

We are getting nearer the “sexy” parts in terms of Exchange 2013, however I will be focussing on installing Certificate Services on your new Domain Controller.

Times change, people change – and as well all know, technology changes as well. The last part of that sentence could not be more true of Windows, Active Directory and Exchange Server recently.

Back in the day (from around 2000 / 2001) – you could set up a working Active Directory / Exchange environment up in your test lab probably in a day. However as the products have evolved over the years the feature set has expanded there is much more to consider, and a number of traditionally familiar ways of doing things have changed.

Whereas it is probably wrong to say that things have become more complex (although to a certain degree this is also true) – the gap between terminology and processes to get your environments up and running has expanded between Windows 2000, 2003, 2008, and Windows 2012.

So, with this borne in mind I have decided to put out an article series which takes you through the process of setting up a simple Exchange 2013 test lab from scratch on Windows Hyper-V server. As I go through the series I will pass on some tips and Powershell scripts which hopefully will make you lives easier – as well as demonstrate some of the areas that have had a major overhaul in both Windows and Exchange.

Configuring Hyper-V

This article is based around Hyper-V 3.0 which shipped with Windows 2012. I am personally using Windows 2012 Core with the Hyper-V role installed, but the processes within this article also apply to Windows Server 2012 Hyper-V installed with the full Windows GUI.

First of all – it is probably best to give you an overview of the topology of the lab environment that I have provisioned for this set of articles along with the specification of each Virtual Machine.

The Hyper-V host is provisioned with a single Inter i7 Quad Core processor and 32 GB of RAM. The server has around 4 Terabytes of usable storage connected via SATA 3, full specifications of the test rig can be found here: http://www.telnetport25.com/2011/11/the-new-test-lab-rig-is-born/

I am running Windows Server 2012 Data Centre Core – with Hyper-V installed on the server.

At the networking layer – I have created two V-Switches within Hyper-V:

• Public V-Switch – used for Public network communications (as an External within the Hyper-V Manager)
• Private V-Switch – used for Private network communications – this will be used as the replication network for Exchange 2013 Mailbox DAGs (as Private within the Hyper-V Manager)

The environment consists of the following servers:

Provisioning the Domain Controller in Hyper-V

To provision the Domain Controller within Windows Server Hyper-V 2012 open the the Hyper-V Manager tool. When the management interface has loaded, from the “Actions” menu (on the right hand side) select [ New-> Virtual Machine ]. This will begin the New Virtual Machine Wizard.

You will be asked to provide a name for your VM (I have used art-DC-01 – but you can call your domain controller whatever your would like). You should also choose the location where you would like the Virtual Machines files – you can either accept the default location that is configured within Hyper-V – or you can tick the “Store the virtual machine in a different location” tick box and select another disk.

When you are done click on the “Next” button.

You will then be asked how much RAM you would like to allocate to your Virtual Machine – in my LAB I have chosen 1.5 GB – you can allocate more, but I would not recommend less. You can also choose to use Dynamic Memory for the VM. When you have finished click on the “Next” button.

You will now need to configure the Network connection that you wish to make available to the Virtual machine. As I mentioned above, in my environment I have two connections, one Public and one Private. Select the connection in your environment that will allow for the VM to be visible to all machines on your network. When you are done click on the “Next” button.

You will then be asked to configure a system disk for your VM. You will need to give it a name, provide the location where you would like it stored (this should be with the VM configuration files), the size of the disk (I am using 110GB). When you are happy click on the “Next” button.

You will then be asked to provide the location of the Installation files for your operating system. I have downloaded the Windows 2012 installation ISO to a location on my Hyper-V host, therefore I choose the option “Install an operating system from a boot CD/DVD-ROM” and located the ISO. You will need to select the option which suites your own and then click on the “Next” button.

You will then be presented with a summary of your configuration options – please take time to review them, then click on the “Finish” button.

Installing Windows Server 2012

When your VM has been provisioned and appears in the Hyper-V Management Console – right click on its entry and from the context menu that appears choose the “Start” option. When then machine has started, again right click on its entry and from the context menu choose “Connect”.

The Windows 2012 setup process should have begun and you should be presented with the Locale screen as per the example below. Choose the options that suit your own configuration best and then click on the “Next” button.

On the next screen click on the “Install Now” option.

You will then be asked to provide your license key for the edition of Windows that you intend to install. Within my LAB the domain controller is going to be running on Windows Server 2012 Standard Edition, but you can provide a key for whatever version you are licensed for. When done click on the “Next” button.

On the “Select the operating system that you want to install” screen – choose the GUI version of the O/S that you provided the license key for in the previous step. When you are done click on the “Next” button.

You will then be asked to confirm that you accept the licensing agreement for the operating system, select the “I accept the license terms” and then click on the “Next” button.

You will then be asked if you would like to upgrade an existing install of Windows, or choose a custom install – select the custom install option. This will give you the chance (should you wish) to customise the disk partitions of your VM. When you are done click on the “Next” button. For the purposes of my LAB I made no changes and gave the entire 100GB to the O/S.

Windows setup will then proceed to install the O/S on your VM – there may be several reboots during this process.

When Windows setup has completed you will be asked to provide a local administrator password for the VM.

When the password has been set – you will be able to log into your new VM and begin the process of configuring it as a LAB domain controller.

Configuring your Virtual Machine

When you have logged onto the VM you will need to configure a number of settings within your Operating System. In order to do this I will take you through how you can use Powershell to modify the following:

• Local Computer Name (as Windows Setup provides you with a default name)
• IP Addressing

Configure Your Computer Name

Open a Powershell session on your VM and at the prompt type:

Rename-Computer <computername>

Therefore in my LAB – my domain controller is to be called art-DC-01 – therefore the command is:

Rename-Computer art-DC-01

You need to restart the VM for the new name to take effect – and this can be done by typing:

Restart-Computer

However if you wish to save time, hold off on restarting your machine until you have configured your IP settings.

Configuring your IP settings

As Powershell has advanced – there are now a number of new cmdlets that let you control a huge number of aspects of your Operating System configuration. Once such advance is the ability to configure IP settings from the shell.

From within your Powershell Window type in the following command:

New-NetIPAddress –InterfaceAlias “Ethernet” –IPAddress <your chosen IP> –AddressFamily IPv4 –PrefixLength 24 –DefaultGateway <Gateway address>

Breaking this command down – some of the parameters might seem a little unfamiliar – therefore:

• -InterfaceAlias – the name of the Network adapter on your system that you wish to apply the address to. When Windows Server 2012 was setup the network adapter that you assigned to the VM will be given the default name of “Ethernet”
• -AddressFamily – stipulates if you are providing a IP4 address or IP6 – in our example we are using IPv4
• -PrefixLength – This is essentially the subnet mask – in my LAB I am using a /24 subnet which translates to 255.255.255.0

Given the above the command for my server looks like:

New-NetIPAddress –InterfaceAlias “Ethernet” –IPAddress 172.31.253.107 –AddressFamily IPv4 –PrefixLength 24 –DefaultGateway 172.31.253.129

It is also a good idea at this point to configure a DNS server (as in the next step you should install any available Windows updates). You can do this from the shell by using the following command:

Set-DNSClientServerAddress –InterfaceAlias “Ethernet” –ServerAddresses <DNS Servers separated via a comma>

Therefore in my LAB I have assigned a DNS server address of 172.31.253.130 using:

Set-DNSClientServerAddress –InterfaceAlias “Ethernet” –ServerAddresses 172.31.253.130

Reboot your computer using the

Restart-Computer

Powershell command and then install any required windows updates.

In the next part

I will take you through how you can install Active Directory on your new Domain Controller.

NOTE: Versions 1.0, 1.1 and 1.2 of this tool have now been superseded by version 2.0 of this tool – you can find the associated article here: http://www.telnetport25.com/2013/01/releasedversion-2-0-of-the-distribution-list-reporting-tool-dlrt/

NOTE: If you would like to install the DLRT on Exchange 2013 – please use the version that has been posted here: http://www.telnetport25.com/2013/02/released-version-2-0-of-the-dlrt-for-exchange-2013/

A couple of organisations that I have worked for over the years have had a need to provide some form of reporting to staff who are employed outside of the IT department that enables some oversight of Exchange Distribution List membership. In the main this has been a requirement from HR departments who have taken on the responsibility of managing Distribution lists within their respective organisations.

Given that management of Distribution lists can be easily delegated – but simple reporting on membership is not (remember for people outside IT using Powershell is probably a “no no”) – I wrote the DLRT (Distribution List Reporting Tool) for those two organisations and decided to release it on my blog; just in case someone else out there is looking for some thing similar.

Pre-Requisites

The following are the pre-requisites for the Distribution List Reporting Tool.

• Windows Server 2008 R2
• IIS 7.0
• .NET Framework 3.5 or above
• Access to Active Directory Users and Computers and the rights to setup a new account in Active Directory and grant “Account Operators” rights
• Exchange 2010
• Exchange 2010 Management Tools installed on the chosen server

Download

Download the following self extracting archive to a server on your network which meets specification in the pre-requisites section.

  [ Distribution List Reporting Tool – Version 1.2 – 168KB ]

Installation and Setup

Double click on the setup file (DistInstallSetup.exe)  that you have downloaded to your chosen server – click on the “OK” button.

You will be asked where you would like to place the installation files – you can either accept the defaults or choose an alternate location, however you should make a note of where you place the files as you will need this information later on. When you are ready click on the “Unzip” button (marked with the green tick).

When the extraction is complete, click on the “OK” button.

When the files have been extracted to your servers – open up Active Directory Users and Computers. Navigate to an appropriate OU or container, right click and from the context menu that appears choose [ New –> User ] (marked with green ticks below).

You will then be asked to create a new user object in the directory. This account will be used for the application pool within IIS for the DLRT. You can call the account whatever you like but, again remember your customisations as you will need them later on when configuring IIS.

Provide a password for your new user account – ensure that you select “User cannot change password” and “Password never expires” – when done, click on the “Next” button.

Confirm the creation of the user by clicking on the “Finish” button.

When you have created your user – you need to add it to the “Account Operators” group in Active Directory. Find the account that you have created, right click on it and from the context menu that appears select the “Add to group” option (marked with a green tick below).

From the selection box that appears type in “Account Operators” and then click on the “OK” button.

You will then be presented with the operation completion dialog – click on the “OK” button.

Next you will need to open up the Internet Services Manager on your server. Navigate to “Application Pools” – right click on the entry and from the context menu that appears choose the “Add Application Pool” (marked with a green tick below).

From the dialog box that appears provide a name for the Application Pool – and ensure that the other options are configured as per the example in the image below.

When the application pool has been created – it will appear in the right hand window pane of the IIS manager. Right click on it and from the context menu that appears select the “Advanced Settings” options – marked with the green tick below.

The Advanced Settings dialog will appear – find the entry for “Identity” and click on the button next to the entry (this is marked with the green tick in the example below).

From the dialog box that appears provide the name of the Active Directory account that you created earlier on.

You are now ready to add the IIS application. On you IIS web server – where you created the Application Pool – right click on the “Default Web Site” entry and from the context menu that appears choose the “Add Application” option – this is marked with a green tick in the example below.

Provide an alias for the application (this will be the end of the URL that you connect to from IE) – in the example below this is “reporter” – therefore the URL would be http://<yourserver>/reporter. Click on the “Select" button for the application pool and choose the pool that you created in the earlier step.

Under “Physical Path” click on the “…” button and browse to the path where you extracted the setup files at the beginning of the setup process. Then you are done, click on the “OK” button.

When the application has been created, select it from the entries under the “Default Web Site” and then from the right hand window pane – double click on the “Authentication” entry.

Ensure that all of the authentication methods listed match the examples provided in the image below.

Using the tool

Open Internet Explorer and navigate to the server URL where you installed the tool – if you have followed the setup above this should be http://<installationServer>/reporter – the will present you with the DLRT landing page. Click on the “Populate” button (marked with the first green tick in the image below) which will then populate the drop down list with all of the distribution lists that have been found. Click on the “Get Members” button to return all members of that lists (this is marked with the second green tick in the example below).

All the members of the list will populate below the drop down list which contains the Distribution Lists. You can click on the “Print” button to send the report to your printer.

If you wish to report on all members of every distribution list in your organisation – click on the “Report on all lists” link at the top of the Reporting Tool screen. Then click on the “Generate” button (highlighted with the green tick in the image below).

The Reporter will then give you a full overview of the membership of all detected distribution lists in your organisation.

I hope that someone out there finds this tool useful.

I have been doing some work with Exchange 2013 over the last couple of days testing some migration scenarios (cannot go into exact detail as a lot of the work is currently covered under Non-Disclosure Agreement [NDA]). What I can disclose is this little tip.

Exchange makes use of a number of System mailboxes which are created setup in the root domain of Active Directory.

Users or administrators cannot login to these mailboxes as system mailboxes are created for internal Exchange features and associated processes within Unified Messaging (UM), migration, message approval, and In-Place e-Discovery.

One of these mailboxes is called:

Migration.8f3e7716-2011-43e4-96b1-aba62d229136

Which unsurprisingly is used for migration and mailbox move activities. Whilst working in my LAB I have been moving some mailboxes around between databases. Today, I was attempting another move – during this particular move I was presented with the following error in the Exchange Administrative Centre.

Now, I wasn’t too surprised at the above error, as I had to forcibly destroy the database which had previously contained the Migration.8f3e7716-2011-43e4-96b1-aba62d229136 mailbox. So, I now needed to get the Migration mailbox back.

Thankfully this is not a terribly difficult process – and involves the following steps:

1. Run Exchange Setup with the following command line: setup /ps /IAcceptExchangeServerLicenseTerms – this will recreate the Active Directory account if it is missing.
2. Open an Exchange Management Shell window and type in the following commands:

Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136"

Set-Mailbox "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" -Arbitration –Management:$true

These commands are shown below.

Once the commands have been entered, the Migration Mailbox should be recreated. If you have multiple domain controllers allow time for domain replication to take place and then retry the mailbox move.

A couple of weeks back an online buddy of mine contacted me to ask some advice. In essence his company was performing some major upgrades to their MPLS network which required some relatively significant changes to hosts that were allowed to relay off of the Exchange Server that was located on his site.

We had a discussion and agreed that they best way to do this was probably to add a new Receive Connector to his Exchange server dedicated to the MPLS and add the relevant Remote IP Ranges to his Receive Connector. Of course this is where it got a little complicated. Well I say complicated – more labour intensive.

You see, my buddies parent company who was managing the MPLS upgrade, had supplied him with a large Excel Spread sheet which contained all of the IP addresses of the hosts which needed to relay off this connector – about 180 entries in total.

Luckily for my buddy (Phil) the Exchange Management Shell was his friend – and by using a simple Text file – a few loops and the Set-ReceiveConnector cmdlet it was pretty easy to put together a Powershell script that would process all of the Remote IP Ranges for him.

Now, I should point out that there are a number of ways in PowerShell that this can be accomplished if you have a look around the Internet – but pretty much all of the examples (including mine) involve concatenating new Remote Remote IP ranges to the existing list on the receive connector and then committing them. My version of the script is designed to make the process of getting multiple IP values out of a text file and added to a specific Receive Connector more straight forward.

The Script

The following is a preview of the script – you can copy and paste it from below to a blank PS1 file on your Exchange Server – or download it from the download section of this post.

<#

.DESCRIPTION

   Simple Powershell script that can bulk import remote IP ranges from a text file in a determined Exchange Receive Connector.

   The Import of the Remote IP ranges maintains the original values which are already present on the Selected Connector.

.PARAMETERS

   None - execute directly from the Exchange Management Shell

.Version

    0.1

.Author

    Andy Grogan

    http://www.telnetport25.com

.Compatibility

   Exchange 2007

   Exchange 2010

   Exchange 2013

.Release Date

    Jan 2013

#>

function Select-FileDialog 

{

      param([string]$Title,[string]$Directory,[string]$Filter="Text Files (*.txt)|*.txt")

      [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") | Out-Null

      $objForm = New-Object System.Windows.Forms.OpenFileDialog

      $objForm.InitialDirectory = $Directory

      $objForm.Filter = $Filter

      $objForm.Title = $Title

      $objForm.ShowHelp = $true

      $Show = $objForm.ShowDialog()

      if ($Show -eq "OK")

      {

            return $objForm.FileName

      }

      else

      {

            exit

      }

}

function get_RecConnector{

    $RecConns = Get-ReceiveConnector | Select -ExpandProperty Identity

    $Count = 0;

    Write-Host "Bulk Import of Remote IP Addresses for Exchange Receive Connectors" -ForegroundColor Green

    Write-Host "Version 0.1" -ForegroundColor Green

    Write-Host "www.telnetport25.com" -ForegroundColor Green

    Write-Host ""

    Write-Host "Detected Receive Connectors: " -ForegroundColor Cyan

    Write-Host ""

    foreach($Connector in $RecConns){

        Write-Host $Count "." $Connector -ForegroundColor White

        $Count ++

    }

    Write-Host ""

    $Choice = Read-Host "Please select the Receive Connector that you wish to work with."

    Write-Host ""

    import_RemoteIPRanges $RecConns[$Choice]

}

function import_RemoteIPRanges{

    param($ConnectorID)

    $FileName = Select-FileDialog "Open IP Range Text File..."

    $IPs = Get-Content $FileName

        foreach($IP in $IPs){

            Write-Host "Adding IP Address :" $IP " to "$ConnectorID -ForegroundColor Cyan

              $Rcnn = Get-ReceiveConnector "$ConnectorID"

              $Rcnn.RemoteIPRanges += $IP

              Set-ReceiveConnector "$ConnectorID" -RemoteIPRanges $Rcnn.RemoteIPRanges

        }

}

get_RecConnector

Write-Host ""

Write-Host "Script Completed." -ForegroundColor Yellow

Download

Exchange 2010 and Exchange 2013

[ BulkImportRemoteIPonRecConn.ps1 – 2.31KB ]

Exchange 2007

[ BulkImportRemoteIPonRecConnEx27.ps1 – 2.2KB ]

Using the script

Download the script file which is relevant to your version of Exchange to one of your Exchange Servers.

In order to run the script you will need to ensure that your Powershell execution policies are set correctly. Review the following post that I prepared last year: http://www.telnetport25.com/2012/02/quick-tip-running-exchange-based-powershell-script-files-from-the-command-line-or-a-batch-file/ to check your settings.

Before you use the script you should ensure that you have all of the IP addresses that you wish to add to a particular Receive Connector stored within a text file.

Each host should appear on a separate line. You can also use the CDIR address notation for an entire subnet if you wish to allow all hosts in a range to relay (for example add a line for 172.31.253.0/24) .

An example file is shown below:

Open the Exchange Management Shell, navigate to the directory where you have downloaded the script file and type:

<path>.\BulkImportRemoteIPonRecConn.ps1

You will then be presented with a list of all the detected receive connectors that the script has located. Choose the connector via its numerical identifier (the numbers on the left hand side).

You will then be prompted to locate your IP Range text file – browse to it and then click on the “Open” button.

The script will then process each host entry and add it to the selected Receive Connector.

After the script has completed – if you check the [ Network –> Receive Mail from remote servers that these IP addresses ] in the Exchange Management Console, you should see that your addresses have been added.

I hope that you find this post and script useful, and that it might help automate this process for someone else in the future.

Over the years, I have installed Exchange Server probably thousands of times. In big infrastructures, little infrastructures and everything in between. Luckily the vast majority of those installs have gone without a hitch – however, there have been some (and those tend to be the ones that I remember the most) that didn’t go so well ~ I affectionately call these the “Smashed” installations).

What I would like to do in this post is take you through some of my own tips when both installing, upgrading and where necessary – recovering from a smashed Exchange install which covers versions of Exchange from 2007 through to 2013. Please note that this is not a Disaster Recovery article – the tips here are about getting new Exchange servers up and running, either in Lab or Production environments and avoiding problems before you encounter them.

First things first – take your time and plan accordingly

Yep, this seems very obvious – I know the feeling, you have installed Exchange countless times, you already have an environment up and running and you just want to get the ISO down and dive into the installation wizard. Long and short of this is don’t do it ~ not just yet.

Planning can be equated to “staking out” your existing environment – e.g. gathering information and researching potential “gotchas” before they happen.

It doesn’t matter if you are working in a vanilla environment, adding new servers to one that already exists or working within a co-existence environment for an upgrade, you should still ensure that you have a plan.

Now there are many levels of planning – but the most pertinent of which I have found is the spend time reviewing almost every aspect that you can think of within the environment that you plan to build, upgrade, or char before you begin the install.

Please do:

• Try any new configuration / setup or upgrade in a test lab where possible.
• Make backups of you AD infrastructure and Exchange Servers / Databases before you make any changes.
• Read all the release notes for known issues, this is especially relevant in the case of Service Packs.
• Check product compatibility with any 3rd party software that might be interfacing or be integrated with your Exchange environment, this mainly effects products such as 3rd party Archival Software – but can extend to CRM / ERP systems, room bookings software etc.

Also take the time to review the following:

• That all Domain Controllers are online within your environment – having a domain controller offline that you are not aware of could cause Exchange Setup to fail. This does not necessarily means just key FSMO role holders (like the Schema master for example), but Exchange setup could try to talk to a “non FSMO role holder” that is a GC which is not working, this could “kill” the install.
• Ensure that Directory Replication is working correctly – DCDIAG is your friend here, if you have replication problems between AD replication partners – then you will probably have issues during Exchange setup, especially during the Schema preparation stages.

However – if you would like to get some more detail which gives you an excellent and very detailed overview of the state of your Active Directory infrastructure – have a look at the following script on the TechNet scripts library by Jon Knapp: http://gallery.technet.microsoft.com/scriptcenter/28812d92-30be-4f37-80cb-ab21b1eeaace

The code is two scripts in one – if you do decide to use it – read the information on the link carefully. Once it is up and running it produces a very good overview of your Directory environment.

• Review all Domain Controller Event Logs for unusual errors or warnings.
• Ensure that DNS is working correctly and that you can resolve both forwarders and reverse – for all DC’s and the Servers on which you intend to install Exchange.
• Like above – ensure that all your existing Exchange servers are online and functioning correctly if you are adding a new server to an existing installation – or performing an upgrade.
• Ensured that all relevant operating pre-requisites and patches are installed BEFORE you install Exchange. Whilst it is true that you can asked Exchange setup to install O/S pre-requisites during the install, this can lead to the installer stopping with the Message “A reboot is pending from a previous installation (for example if you let Setup install the RSAT tools). It is always a good idea to get all reboots and installs out of the way before you install Exchange.
• Linked to the above tip – if you have installed any recent O/S updates via Windows Update or a management tool such as System Centre Configuration Manager – ensure that any outstanding reboots have completed.
• Take the time to ensure that relevant system mailboxes (these are called arbitration mailboxes) are working as you would expect. In the past I have had Exchange setups (and upgrades) fail, because certain arbitration mailboxes have been orphaned from their mailboxes store (this is often caused by someone forcibly deleting a mailbox store using ADSI edit from AD)

You can check this by running the following Exchange PowerShell cmdlet before you run setup:

Get-Mailbox –arbitration | Select name,Database

If there is a problem you should see an error message similar to the following:

Name                                                        Database
----                                                        --------
SystemMailbox{1f05a927-ac84-48a8-9e9b-03a88581d504}         prod-ex2010-01-General-2
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042         pri_Commercial_01
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}         pri_Technology_01
Migration.8f3e7716-2011-43e4-96b1-aba62d229136
WARNING: The object prepAD.local/Users/Migration.8f3e7716-2011-43e4-96b1-aba62d229136 has been corrupted, and it's in
an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.

You often can repair errors like the above by running Exchange Setup again with the setup /prepareAD command line – full details of the process are detailed here: http://social.technet.microsoft.com/wiki/contents/articles/5317.recreate-and-enable-missing-arbitration-user-accounts-and-mailboxes-in-exchange-server-2010.aspx

• If you are using any “Agent Based” monitoring tools such as System Centre Operations manager which maintain locks on critical files on a monitored host, or any monitoring tool that will take corrective action when a key service goes offline (MSExchangeIS for example) – disable them before you begin setup.
• If you are running any File Level anti-virus products – you should ensure that these are not monitoring any Exchange files, critical paths or critical services (as per http://technet.microsoft.com/en-us/library/bb332342(v=exchg.141).aspx (for Exchange 2010) or http://technet.microsoft.com/en-us/library/bb332342.aspx (for Exchange 2013) – these can interfere with the setup process.

Preserve your log trail for troubleshooting later on

Before you install Exchange, review and preserve your Event and Setup logs – in particular:

• Before you begin an install – Export the event logs from the servers that you are working on and save them to a safe location.
• Clear the event logs – this might seem like a crazy idea – but if you have exported them (as in the previous tip) – then you have preserved the historic data. Clearing the logs just before you begin setup means that if something should go wrong it is easier to filter out the relevant events.
• When Exchange setup runs a folder called ExchangeSetupLogs is created in the root of the system boot drive (typically C:\). This folder is like gold dust if something goes wrong – however there are some things that you should know about the contents of this folder:
  • Each time Exchange Setup runs a large amount of data is input into the files in this folder. These files are a mix of text log files, PowerShell files, and Dr Watson Reports. As a tip I recommend that you take a copy of this folder after each setup run. Each time setup is executed a number of the files are appended to – which can make them harder to search.
  • If you take a copy after each setup run you effectively create a point in time set of logs for each install attempt which you can look at in isolation and compare if you need to.
  • If you need to effectively analyse the logs created in the ExchangeSetupLogs it is worth taking a look at the Get-SetupLog.ps1 script which is located in the $exscripts folder in Exchange 2007 and 2010 versions of Exchange.

The full overview of how you can use the script is provided here in the following post on the MSExchangeTeam blog – but the loose gist is as follows:

Open an Exchange Management Shell and type in:

cd $exscripts

.\Get-SetupLog.ps1 <path to Exchange Setup Log file>

The above above command will produce verbose output from the script.

If you use the following command

.\Get-SetupLog.ps1 <path to Exchange Setup Log file> –error $true

This will scale down the output from the script to relevant warnings and errors.

As you can see from my output, the problem with the Exchange setup that I was using in the example above was down to missing arbitration accounts – see below:

0.  ErrorRecord: Microsoft.Exchange.Data.DataValidationException: Database is mandatory on UserMailbox.
[ERROR] The following error was generated when "$error.Clear();
[ERROR] The following error was generated when "$error.Clear();
[ERROR] Database is mandatory on UserMailbox.
1.  ErrorRecord: Database is mandatory on UserMailbox. Property Name: Database
1.  ErrorRecord: Microsoft.Exchange.Data.DataValidationException: Database is mandatory on UserMailbox. Property
Name: Database
[ERROR] The following error was generated when "$error.Clear();
[ERROR] The following error was generated when "$error.Clear();
[ERROR] Database is mandatory on UserMailbox. Property Name: Database

The article on the MSExchange team’s site mentions some further formatting scripts which can dump the output to HTML – however clicking on the link redirects to a 404 page. However, I have found that if you need to keep the data you can use the PowerShell Start-Transcript cmdlet – like so:

Start-Transcript –path <path to transcript file>

.\Get-SetupLog.ps1 <path to Exchange Setup Log file> –error $true

Stop-Transcript

You can then use a text editor such as Notepad++ to review the formatted output file.

Just for information – this script does not appear to be included with Exchange 2013 – however from some of the testing that I have done, it works with the Exchange 2013 setup logs as well.

Other tips that you might find useful

• If you are having trouble restarting setup after a failed installation on a specific role, and you are getting an error message similar to the following:

Setup previously failed performing action: x

Setup might then terminate.

In order to fix this problem you will need to open up the Registry Editor and navigate to the following location:

HKLM\Software\Microsoft\ExchangeServer\V(14, 15)

Under this key you will see entries for each Exchange Role that has been installed – click on each key and look for the “Action” and “Watermark” entries – delete them and then begin setup again.

• If you are adding servers to an existing Exchange 2010 environment, co-existing with Exchange 2007 take the time to run the Exchange BPA ~ this should identify any major issues before you make any changes to your environment.

There are – of course many other tips available on the web to help you with a safe install or upgrade for you environment which I urge you to seek out – but I hope that you find my own personal brain dump useful.

I have been working on a few Exchange installs recently which have not gone completely according to plan. Normally when Exchange setup fails my first stop are the logs which are produced by the Exchange Setup process. These are typically located in “c:\ExchangeSetupLogs”.

There are normally quite a lot of files within this folder which detail the steps, processes, return results and errors of the Exchange setup processes. These files typically contain large amounts of data (as you would expect) so going through them manually can be a bit of a pain, unless of course the error is obvious!

However, in Exchange 2007 and 2010 – Microsoft provide a script in the $exscripts folder which helps “parse” the output of the logs files to make it easier for you to interpret the output. This script is called Get-SetupLog.ps1 and is covered in detail in this post over on the MSExchangeTeam’s blog.

Interestingly enough this script does not appear to be present in the $exscripts folder in Exchange 2013 – however, it appears that it still works with Exchange 2013 setup logs.

Anyway – back to my failed Exchange setups. I found that one the server where Exchange setup had failed I was getting the following error when trying to run the script:

Exception calling "Add" with "1" argument(s): "String was not recognized as a valid DateTime.Couldn't store <12/30/2012 20:13:52.0010> in DateTime Column.  Expected type is DateTime." At C:\Program Files\Microsoft\Exchange Server\V14\scripts\get-setuplog.ps1:107 char:52 + $currrow = $dataset.Tables['setuptable'].Rows.Add <<<< ($holder) + CategoryInfo   : NotSpecified: (:) [], MethodInvocationException + FullyQualifiedErrorId : DotNetMethodException

The command line that I had used was:

.\get-setuplog.ps1 <path to Exchange Setup Logs>

After some investigation in my lab I found that on some of my Exchange servers the script would run correctly, however on others it would give me the errors shown above. The interesting thing that I noticed about the above PowerShell error was that it was being thrown when the script was attempting to parse DateTime values into a DataSet.

This started me thinking about what could be causing this – and what the difference could be between the servers where the script executed correctly and where it didn’t. I came up with Regional and Locale settings.

Sure enough, I found that on the server where the script ran correctly; the Regional Settings were set to en-US (United States) – and the server where the script did not run were set to en-GB ~ I tested this by changing the Regional settings on one of the servers in the lab and the script then ran fine.

Now, I did not wish to set the Regional settings to the USA on all my servers just to run the Get-SeupLogs.ps1 so I decided to have a look at the guts of the script.

I opened the Get-SetupLogs.ps1 script in a text editor – and found the following definition of the DataSet that is used to store the data when parsing the logs.

$dataset = new-object System.Data.Dataset 

$dataset.Tables.Add('setuptable') 

[void] $dataset.Tables['setuptable'].Columns.Add('SetupRun', [int])

[void] $dataset.Tables['setuptable'].Columns.Add('Depth', [int])

[void] $dataset.Tables['setuptable'].Columns.Add('DateTime', [DateTime]) 

[void] $dataset.Tables['setuptable'].Columns.Add('Description', [String])

[void] $dataset.Tables['setuptable'].Columns.Add('Status', [String])

The line that I was interested in was:

[void] $dataset.Tables['setuptable'].Columns.Add('DateTime', [DateTime])

I changed the line to look like the following:

[void] $dataset.Tables['setuptable'].Columns.Add('DateTime', [String]) # Was DateTime

In essence, rather than trying to parse any date value within the log file being processed to a DateTime it would be processed as a normal string.

After making this change the script ran correctly.

Now I don’t know if this is a problem that is peculiar to my own setups, or the script prefers a US based locale (there is nothing to suggest in the file that it does) – but if you should encounter this problem, the above is a workaround that can used.

Information

WinWOL is a free and simple Wake on LAN tool for Windows. WinWOL is a small, portable .NET framework application which allows for you to build a list of common computers on your network infrastructure that you like to “wake up” remotely.

Download

You can download the WinWOL tool from the following location.

[ WinWOL – Version 1.1 – 170KB ]

User Guide

You can download the WinWOL user guide from the following location.

[ WinWOL – Users Guide – 350KB ]

Change History

Version 1.0 – Initial Release

• Now retired

Version 1.1

• Complete interface re-design to allow for easier discovery and “waking” of remembered hosts.
• Re-compiled against version 4.0 of the .NET Framework.
• New Feature: Double click to wake feature added to the “Remembered” hosts window.
• New Feature: Added in name resolution of remembered hosts.
• Added in an ‘About Box’
• Enhanced error handling.
• New User and Installation Guide.

A few weeks ago I took a bit of break from work and all things Exchange and sat down to write what I call some “self help tools”. In essence, every now and then I write small utilities to make laborious administrative processes easier to manage. One such tool that I needed was a simple “Wake on LAN” application. I won’t bore you will all the details; but suffice to say I have a large amount of machines to turn on each day and by having a “point and click” list would make things far easier for me.

The other reason why I wrote the tool, was because I wanted to spend sometime writing an application in an area which I do not normally focus on.

I was quite pleased with the end result, so I decided to put it up on the site for download should anybody else wish to give it a try.

Pre-Requisites

• .Net Framework 4.5.
• Windows Vista, Windows 7, or Windows 8 (x32 or x64).
• The WOL features enabled on the relevant hosts network card (this is often enabled within the BIOS of the destination computer – please refer to your manufacturer’s user guide for further information).

Firewall Requirements

• In order to use the network discovery features of WinWOL – all the relevant endpoint clients which you intend to “Wake UP” should allow ICMP traffic from the management machine (e.g. the machine where you have installed WinWOL).
• The tool can be used WITHOUT the network discovery, but you will have to MANUALLY enter in IP and MAC addresses for your endpoints.

Download

You can download the WinWOL tool from the following location.

[ WinWOL – Version 1.0 – 168KB ]

User Guide

You can download the WinWOL user guide from the following location.

[ WinWOL – Users Guide – 350KB ]

I read with great interest today Michel de Rooij’s “A short retrospective” summarising 2012 on his excellent blog EighTwoOne #821. I thought that was pretty cool.

Michel and I both use WordPress as our blogging platform – and one the many things that WordPress does is (if you are either blogging directly on WordPress.com or have your hosted sites connected to Jet Pack) they provide you with some “fun” stats for your site each year.

Given that I liked Michel’s so much – I thought that I would share some of mine.

Wow – more visitors than Liechtenstein? It’s odd as I have been to Liechtenstein and it is a great place; and I am sure that it is more fun than my blog! – Maybe I can set up some kind of tourist economy for telnetport25.com in 2013, then again perhaps not.

I am still amazed at the amount of people who visit my blog, and of course grateful for their (your) continued support. I will be hoping to keep posting on through 2013 – and there are many cool topics to get my teeth into, especially in light of the Wave 15 products that have been released in 2012.

It seems that I get most of my traffic from forums and from Paul Cunningham’s rather cool Exchange Server Pro website (please visit if you have not already done so) – interesting to see that I get some reasonable traffic from Facebook. I have to admit that I have not done as much with the telnetport25.com Facebook page as I would have liked – definitely something to focus on in 2013.

Interestingly enough, WordPress thinks that I have had visitors from 208 countries! I had a quick look online and there is some conjecture about exactly how many nations there are – but the popular vote is around 196. Mind you, when you bring into the equation things like Recognised States, Observer States, Dependant territories etc. that figure does rise to about 249.

So – should I claim that my blog has technically had a visit from almost every country in Earth? or do I think that perhaps this little stat is open to interpretation?, Bugger it – I am going to claim that telnetport25.com created several new nation states in 2012, one of which is called “telnetport25.com” (if you look hard enough on the world map you will see it in between Greenland and Norway!)

Anyhow, I hope that you have enjoyed this little run through and you have enjoyed telnetport25.com over the last year. I would like to thank you all from the bottom of my heart for your continued support, comment and suggestions. This only leaves it for me to say – please have a happy and safe new year for 2013.

Around three years ago I released a small command line based tool which forcibly removed the Exchange related attributes from a user within Active Directory. The original rationale behind writing the tool was:

There have been many points over the years where I have personally (not sure if anyone else out there has encountered this) where I have forcibly needed to disassociate (or remove) a user account from its mailbox.

Normally this would be accomplished via the Exchange Management Shell using the Disable-Mailbox or the Remove-Mailbox -StoreMailboxIdentity -Database CMDLETS in a production environment.

However if you have found yourself in the situation where the Mailbox Server has been rebuilt without an suitable backup – or more to the point where Exchange has been forcibly removed from Active Directory which results in having a number of accounts which point to a Mailboxes on a Mailbox Server that no longer exists – I am sure that you are aware of how much of a pain it is to rummage around in AD – remove the required attributes for all of those accounts and reconnect them.

Recently I found myself in the situation again (through me messing something up in my lab (again!)) – and I needed to remove the attributes from a number of accounts. I went to my old tool – and found that whilst it worked ~ it was not particularly good when you needed to use it in bulk.

I also found that due to the various changes that have happened in Exchange since I released the original code – there were a number of attributes that the tool does not clear up as they were not present on the user properties at the time (there have been a number of schema updates which have added properties to user mailboxes).

So, I decided to rewrite the tool so that it was capable of working on multiple mailboxes and add in some additional attributes to be removed that have been added into Exchange since version 1.0 of the tool was published.

Warning

The REA is HIGHLY destructive – it is designed for use in very particular circumstances, and only as a last resort. I cannot be held responsible for any data loss that might occur as a result of using this tool. Please ensure that you understand the ramifications of using this tool against a WORKING mailbox(es):

• The Active Directory Account will be orphaned from the Mailbox within the database

This tool is designed for use against Active Directory accounts where the mailbox, mailbox database or server are no longer available and the normal Exchange cmdlets do not work.

Microsoft does not, and will not support this use of this tool – use at your own risk!

Requirements

• .Net Framework 3.5 Service Pack 1
• Exchange 2010 and Exchange 2013 – Only
• Needs to be executed in the context of a Domain User account

Download

[ REA – Version 2.0 – 1.6 MB ]

Installation

Double click on the installation binary file “REA.exe”.

You will be asked if you wish to continue with the installation – click on the “Yes” button if you wish to proceed.

Select your desired location for the main tools binary to be placed (remember this location as the installer does not create icons in the Start menu) When done click on “Unzip”.

When the process has completed you will be presented with the “Successful” dialog box – click on “OK” to exit.

Start the tool by double clicking on the tool binary file from the location where you installed it during the installation process.

Usage

When the tool has executed – in the “samAccountName” field type in the account name of user that you wish to forcibly remove the attributes of.

When done, click on the “Search” button.

The account details pane will populate – review the information to ensure that you are happy to proceed.

Click on the “Add >>” button which will transfer the account to the “Selected Mailboxes” window. Repeat the process to add further accounts for processing.

When ready – click on the “Remove” button. The tool will then process each account and remove all of the relevant Exchange attributes from the account.

The old version of tool will remain available as it is still compatible with versions of Exchange from 2003 to 2007.

Dear all, just a a very quick post to wish you all, including your families a very Happy Christmas. Currently sitting here with a small (large) glass of vino, reminiscing on my personal highlights from 2012. I hope that you all continue to enjoy telnetport25.com (I have renewed the hosting for another year; so I intend to keep posting as regular as I can).

With love and peace – Andy G

Not quite an Exchange post, but technically related depending on your circumstances. Today I decided to “bite the bullet” and migrate all of my Virtual Machines to Windows Hyper-V 2012 server away from Windows 2008 R2 with Hyper-V 2.

There were a number of reasons why I wanted to do this:

1. My current test rig was using Windows Server 2008 R2 with Hyper-V 2. I was also using Microsoft Virtual Machine Manager 2012 – this all culminated in a base memory utilisation of about 2.3 – 3GB of RAM before I had even booted up a Virtual Machine instance. As Windows Hyper-V Server is based on a cut down version of Windows Server Core (containing just the Virtualisation components) The memory overhead is slightly less at around 1.2 GB.
2. I had a full O/S running on the server which was probably a waste of a license given that I did nothing else with it aside from run virtual instances – if I had less to update and manage I could simplify my environment.

Of course, moving to this new platform presented its own set of unique challenges, not least of which the loss of a GUI – which (as I found) was about to cause me a number of issues in the context of installing drivers.

The Problem

Although Hyper-V 2012 Server installed with no issues – The problem that I had straight away was a lack of network connectivity. The Asus P8Z68-V PRO has an on-board Intel 82579LM Network Interface Adapter (see below)– which is a traditional Desktop based NIC, and unsurprisingly neither Asus or Intel supply native drivers for server operating systems.

Now, this is not a huge problem, as generally speaking the driver software does not vary a huge amount between Windows 8 and Windows Server 2012 – so the theory is that you can download the Windows 8 driver which will work correctly with Windows Server 2012. However the truth is that it does, but not without a bit of messing about!

The driver packs from either Asus or Intel contain no provision within the Windows 8 installation INF files to allow for an installation on Windows Server 2012 Server. So, you have to bodge the INF file so that the installation process will work on the server platform.

Modifying the Driver Pack

I downloaded the Intel Driver from Intel’s website and extracted the contents to a folder on my local PC. Within the extracted package there was a folder called “PRO1000” (Pro drivers for Gigabit Network Adapters). I drilled down further within PRO1000 to WinX64\NDIS63\ and located the file entitled “e1c63x64.inf” this is the INF installation file for Windows 8 x64 platforms for the 82579LM NIC.

I opened the file in Notepad and located the [ControlFlags] section (see image below) – I removed all entries (but not the ControlFlags section).

I then located the section [Intel.NTamd64.6.2.1] – selected the last 3 highlighted entries (shown the image below) and copied them to the clipboard:

I then pasted these to the bottom of the entries located in the [Intel.NTamd64.6.2] section – see the image below.

I then saved the INF file.

Installing the Driver on Windows Hyper-V Server 2012

This process needs to be done from the command line on Windows Hyper-V Server 2012 – however, before this was attempted I needed to disable the “Driver Signature Enforcement” security function on Windows Hyper-V Server.

In essence most drivers and associated files from reputable manufacturers are signed with a unique digital ID. By modifying the INF file – it no longer conforms to the signature within the package catalog file – so Windows will choke and not install the driver.

I disabled Driver Signature Enforcement by executing the following commands at the Windows Hyper-V Server 2012 command line:

bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS

bcdedit /set TESTSIGNING ON

bcdedit /set nointegritychecks ON

After entering the above commands I rebooted the server. When the server had restarted I checked to see that my options had been configured by running the bcdedit command with no parameters – which produced output that looked like the following:

I was now ready to install the modified driver package onto my system. Now, as there is no GUI in Windows Hyper-V Server 2012 you cannot use the GUI install for drivers software – you need to manually install using the pnputil tool.

I copied the relevant files over to the server and then from the command line typed:

pnputil –i –a h:\<path>\e1c63x64.inf

The process then started and I was prompted if I really wanted to install the unsigned driver – to which I said yes. The install completed successfully.

I then rebooted the server – where I then found that I had network connectivity.

To tidy up, I then switched Driver Enforcement back on (for security reasons) but using the following commands:

bcdedit /set LOADOPTIONS ENABLE_INTEGRITY_CHECKS

bcdedit /set TESTSIGNING OFF

bcdedit /set nointegritychecks OFF

I hope that someone might find this useful if they find themselves in the same (or similar situation). The above process can also apply to Windows Server 2012 Core edition.

Program Description

The EBUCT is designed to create mailboxes within Exchange 2013 in bulk from pre-existing accounts in Active Directory. This is currently a feature which is missing from the Exchange Administrative Centre in the RTM and Exchange 2013.

Prerequisites

This software should be executed from a server or computer which has the Exchange 2013 Management tools installed. The tool also requires version 4.0 of the .NET framework in order to execute.

Download

[ EBUCT.exe – 720KB ]

Relevant Links

The following posts contain a full overview and description of usage for the EBUCT.

• http://www.telnetport25.com/2012/11/ebuctexchange-2013-bulk-user-creation-tool/
• http://www.telnetport25.com/2013/04/released-exchange-bulk-user-creation-tool-v2-0-ebuct-2-0/

Revision History

Version 1.0.0.0 – 04/11/2012

• Initial release – now retired

Version 1.0.0.1 – 05/11/2012

• Changed Interface “Select / Unselect all Mailboxes” to “Select / Unselect all Active Directory Accounts”
• Changed “www.telnetport25.com” located in the status bar to be an active and clickable URL
• Moved the enable mailbox process bar to be next to the enable button
• Added in a progress status label
• BUG FIX: Fixed Directory Accounts with special characters within the name (samAccountName) were not processed correctly
• BUG FIX: The “Select / Unselect all Active Directory Accounts” check box was not unchecked when all processing had been completed

Version 1.2.0.0

• Re-compiled the tool so that it will run with version 4.0 of the .NET Framework, some people reported issues with 4.5 as they were not running it.
• Added in Event Logging Diagnostics: The EBUCT creates an Event Log under Applications and Services called ExchangeEBUCT – relevant information from the tool is logged here

 Version 2.0 – 26/04/2013

• Redesigned interface to make the software more simple:
  • Removed the need to select Directory users from the from the “Active Directory Users without Mailboxes” to the “Selected Users section”. You can now just check the accounts in the Treeview.
  • Added in a ‘File’ menu which allows for the application to be exited from a menu command.
  • Added in an ‘About’ box.
  • Flattened the user interface buttons.
• New Feature: Search for a specific account within the Active Directory Treeview.
• Error Handling: Added in some enhanced error handling scenarios which in previous versions could result in the tool raising an Exception.
• Error Handling: Program will notify you if you try and enable an account without having selected a Mailbox Database.
• Error Handling: Program will notify you if you have not selected at least one Active Directory Account.

Script Description

This PowerShell based script will create a shortcut to the Exchange Administrative Console for Exchange 2013 on the Desktop of each Exchange 2013 server which hosts the administrative tools.

Download

[ CreateExchangeAdminCentreIcon.ps1 – 1.5KB ]

Usage

Please refer to the following article(s):

• http://www.telnetport25.com/2012/11/quick-tipcreating-an-icon-on-the-desktop-for-the-exchange-2013-eac/

NOTE: I have updated the version of the EBUCT.exe from version 1.0.0.0 to 1.0.0.1. The new build contains minor bug fixes that I have found since its release on the 04/11/2012. I have also made some very cosmetic changes to the user interface – the guidance below is still relevant and covers the appropriate use of the tool. For full revision history – please refer to the download page located here: http://www.telnetport25.com/2012/11/ebuctexchange-2013-bulk-user-creation-tool-2/

NOTE (14/04/2013): I have provided another update to the tool (now at version 1.2.0.0) where it is now compiled using version 4.0 of the .NET framework (some people were reporting problems as they did not have version 4.5). The tool now also creates an Event Log under Applications and Services so diagnostic information can be written about the tools execution. The new version can be downloaded from the link in the previous “note” section – or from the download area below. I have also fixed a bug for environments which only have a single mailbox database.

NOTE (26/04/2013): I have released version 2.0 of the EBUCT – available here: http://www.telnetport25.com/2013/04/released-exchange-bulk-user-creation-tool-v2-0-ebuct-2-0/

From my own perspective, whilst I love the new EAC (Exchange Administrative Centre) within Exchange 2013 – there is one thing that really annoys me – and that is the inability to create mailboxes in bulk for accounts that already exist within Active Directory from within the GUI – see below:

I should point out that it s possible to create mailboxes in bulk from the Exchange Management Shell in Exchange 2013 using the following management shell cmdlet:

Get-User -RecipientTypeDetails User -Filter { UserPrincipalName -ne $Null } | Enable-Mailbox

However – to my mind is a bit of a “blunt” tool – and I would like more control over the process – e.g. being able to choose specific mailboxes to be created in specific databases which the above PowerShell cmdlet does not allow for without significant modification.

So, I decided to break out my trusty copy of Visual Studio and write a little application which provides the same basic functionality for Exchange 2013, that was present within the MMC based Exchange Management Console in Exchange 2010.

Download

You can download the Exchange 2013 Bulk User Creation Tool from the following link. You will need to have version 4.0 of the .NET framework installed as well as the Exchange 2013 management tools.

[ EBUCT.exe – 650KB ]

Usage

Double click on the program icon to launch the executable “EBUCT.exe”

During execution (and depending on your systems security configuration) you might be presented with the following dialog box:

If you are presented with this message click on the “Quit” button. Right click on the EBUCT.exe program file and from the context menu that appears select “Properties”.

When the properties dialog appears – click on the “Compatibility” tab – and then check the "Run this program as an administrator” check box from the “Privilege level” area and then click “OK” – see below.

The EBUCT should then run correctly.

NOTE: The program notifies you about this, as during start up it tries to create an Event Log under Applications and Services – this is a privileged operation and needs your permissions to do so.

The main program window will then appear – click the “Refresh” button – this will retrieve a list of all the accounts in Active Directory which do not currently have a mailbox assigned and also populate the “Mailbox Databases” area. The program is designed to ensure that sensitive accounts within the directory are not shown in the list. You can also alter the number of accounts retrieved by selecting (or entering) a value from the “Number of users” drop down box.

From the “Active Directory Users without Mailboxes” area – select the accounts that you wish to create mailboxes for – if you wish to select all accounts – check the “Select / Unselect all mailboxes” label. When you are happy with your selections click on the “Select Users” button – this will transfer them to the “Selected user accounts” area.

Select the desired database from the “Mailbox Databases” area – then click on the “Enable” button.

The program will then create the mailboxes, and when completed reset ready to create another batch.

Checking Events

Hopefully the EBUCT will work with no issues, however if you should run into problems you are always welcome to e-mail me with the problem that you are experiencing. Before you do so, it would be good if you could have a look within the Event Viewer and navigate to [ Event Viewer (Local) –> Applications and Services Logs –> ExchangeEBUCT ] and provide me with the data which is contained within the log – see below.

I hope that you find the above tool useful.

This is a very quick tip (with a script) that enables you to create an icon for the Exchange Administrative Centre in Exchange 2013 on your desktop. Whilst perhaps not the most earth shattering tip – and indeed it is one that is aimed at administrators who are less familiar with Exchange 2013 in some cases it proves quite useful.

For those of you who don’t know, Exchange 2013 has disbanded the concept of the traditional MMC based interface for administering Exchange, and adopted a new web based interface called the “Exchange Administrative Centre” (or EAC for short).

When you install Exchange 2013 – a link to this management interface is not created by default – and administrators have to use a URL similar to the following: https://ExchangeServerName/ecp from within Internet Explorer.

The following script will create a shortcut to the EAC on your administrative desktop:

<#

.DESCRIPTION

    Create EAC Admin Link for Exchange 2013

.CREDITS & COPYRIGHT

    2012 (c) Telnetport25.com

    Author: Andy Grogan

.VERSION

    1.0

#>

Get-PSSnapin Microsoft.Exchange.* -Registered -ErrorAction SilentlyContinue | Out-Null

if(!$?){

    Write-Host "The Exchange Management Admin Tools are not installed on this server." -ForegroundColor Red

    Write-Host "This script should be executed on an Exchange 2013 server with the management tools installed." -BackgroundColor Red -ForegroundColor White

    exit(1)

}else{

    Write-Host "The Exchange Management Tools are installed." -BackgroundColor Green -ForegroundColor Black

    Write-Host "Creating Icon..." -ForegroundColor Green

    $ServerName = $ENV:COMPUTERNAME

    $Name = "Exchange 2013 Administrative Centre" 

    $Target = "https://$ServerName/ecp"  

    $WSO = new-object -com "WScript.Shell" 

    $path = $WSO.SpecialFolders.item("AllUsersDesktop") 

    $URL = $WSO.CreateShortcut( (join-path $path $Name) + ".lnk" )  

    $URL.TargetPath = $Target

    $URL.IconLocation = "https://$ServerName/owa/auth/15.0.516/themes/resources/favicon.ico" 

    $URL.Save()

}

I have personally found this to be quite useful – especially if you run the script just after you have installed Exchange 2013. Of course you can do this manually should you wish to by dragging and dropping the URL from the IE address bar to your local desktop – but if you have a number of Exchange Servers – you may wish to use the script to automate the process.

Download

[ CreateExchangeAdminCentreIcon.ps1 – 1.5KB ]

Usage

In order to use the script – download it to your Exchange 2013 server and follow the guidance for running PowerShell scripts that I have provided here. Alternatively you can copy the code above to a new PS1 file on your Exchange Server.

Today I have been busy removing the Release Preview of Exchange 2013 from a number of my lab servers. All was going well until I came to removing Exchange from a couple of Exchange 2013 DAG Servers – where I was presented with the following error message:

Error: This computer is a member of a cluster. It must be removed from the database.

Prior to my attempting to remove Exchange I had removed all database copies that had been associated with the server.

Luckily the solution was very simple.

In order to resolve this error message, open a PowerShell command window and type in the following commands:

Cluster node

This will list all of the Exchange Servers that are associated with the Failover Clustering service – identify the name of the Exchange server that you are trying to remove Exchange from – then type:

Cluster node <Node Name> /Evict

When the node has been removed from the cluster type in the following PowerShell cmdlet

Remove-WindowsFeature Failover-Clustering

You can then close the PowerShell window and return to the Exchange 2013 RP setup process and click on the “Retry” button – and which should then result in the removal prerequisites completing correctly.

The May – Sep 2012 www.telnetport25.com newsletter(s) are available for download from the following location:

[ May - Sep 2012 Newsletter – 600 KB ]

A couple of weeks back I published a very simple script which I had been using on a few versions of Exchange to determine the physical sizes of each of the EDB files. A reader commented that in Exchange 2010 – such an elaborate script was not needed as the Get-MailboxDatabase cmdlet contains a “DatabaseSize” property which is populated from the Information Store on each mailbox server when the “–Size” parameter is used.

Bjarni Kristjansson

Or this one liner… Get-MailboxDatabase –server <ServerName> -status | select ServerName,Name,DatabaseSize
Rgds. BK

Of course Bjarni was correct – but his comment led me to consider how I had been using my original script. As I was familiar with the code and the environments that I was executing it within – I would modify it to essentially “work” when it stopped doing so – however, when I published a version of the the code on telnetport25.com – I discovered that what I produced was not all encompassing (or generic enough). Therefore;

• Execution against Clustered 2007 Instances would not return any data
• The script did not account for different versions of Exchange, and therefore did not use the most optimal command line syntax between 2007 and 2010

Given the above I have re-written the original script (and replaced the download with the new script) so that it will now:

• Recognise the different syntax between the cmdlets required by Exchange 2010 and Exchange 2007
• If the host environment is Exchange 2007, determine if the mailbox is hosted on a cluster or a basic Exchange instance and report on the physical database sizes

In order to work correctly in an Exchange 2007 environment the account in which the context of the script is run needs to have access to the hidden share at the root of each Exchange server (c$ for example).

Aside from the mail purpose of the script, there are some other learning points contained within its syntax – for example;

• Exchange 2007 / 2010 – How to simply detect the major version of the Exchanger on a given server
• Exchange 2007 CCR – How to determine the Active CCR node

The output of this script looks like the following depending on the version of Exchange that it executes against:

Exchange 2010

Exchange 2007

The (revised) Script

You can review the script below, or you can click on the download link provided in the Download section.

   1: <#

   2: .DESCRIPTION

   3:    Sample Script to demonstrate how you can get the physical Database Size for both Exchange 2007 and 2010

   4: .CREDITS & COPYRIGHT

   5:     2012 (c) Telnetport25.com - Released under the GNU version 3.0

   6:     Author: Andy Grogan

   7: .VERSION

   8:     2.0 - Revised Version

   9: #>

  10:

  11: function GetExchangeMajorVersion{

  12:     param(

  13:

  14:         $ExchangeServer

  15:

  16:     )

  17:     $SVR = Get-ExchangeServer $ExchangeServer

  18:

  19:     # Build a simple differentiation between Exchange 2007 and 2010

  20:

  21:     if($SVR.AdminDisplayVersion.Major -eq 8){

  22:         return "2007"

  23:

  24:     }elseif($SVR.AdminDisplayVersion.Major -eq 14){

  25:         return "2010"

  26:     }else{

  27:         Write-Host "This script is not supported on versions of Exchange prior to 2007" -ForegroundColor Red

  28:     }

  29:

  30: }

  31:

  32: function get_isACluster{

  33:     param ($Server)

  34:

  35:     $isCluster = Get-MailboxServer -Identity $Server | Select Name,ClusteredStorageType

  36:     if($isCluster.ClusteredStorageType -ne 'Disabled'){

  37:             return "Clustered"

  38:         }else{

  39:             return "notClustered"

  40:         }

  41: }

  42:

  43: function get_ActiveNode{

  44:     param(

  45:

  46:         $Server

  47:

  48:     )

  49:     $2007Cluster = Get-MailboxServer $Server

  50:     if($2007Cluster.ClusteredStorageType -ne "Disabled"){

  51:            $Stat = Get-ClusteredMailboxServerStatus $2007Cluster.Name | Select -Expand OperationalMachines | foreach {if($_ -like "*Active*") {$_}}

  52:            $AN = $Stat.Split(" ")[0]

  53:            return $AN

  54:     }

  55: }

  56:

  57: function get_DBSize2007Cluster{

  58:     param(

  59:         $Server, $DatabaseName

  60:     )

  61:         Write-Host "Working on Mailbox Database Server: " $Server -ForegroundColor "White"

  62:         $aNode = get_ActiveNode $Server

  63:         $thisDB = Get-MailboxDatabase -Identity $DatabaseName

  64:         Write-Host "Working against database: " $thisDB -ForegroundColor Green

  65:         Write-Host "Operational Cluster Node: " $aNode -ForegroundColor Yellow

  66:

  67:         $Path = "`\`\" + $aNode + "`\" + $thisDB.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $thisDB.EdbFilePath.PathName.Remove(0,2)

  68:         Write-Host $Path

  69:         $EdbFile = Get-ChildItem $Path

  70:         $DBSize = $EdbFile.length / 1GB

  71:         $Result = [Math]::Round($DBSize,2)

  72:         return $Result

  73:

  74: }

  75:

  76: function get_DBSize2007NONCluster{

  77:     param(

  78:         $Server

  79:     )

  80:         Write-Host "Working on Mailbox Database Server: " $Server -ForegroundColor "White"

  81:

  82:         $DBS = Get-MailboxDatabase -Server $Server

  83:

  84:         foreach($DB in $DBS){

  85:             Write-Host "Working against database: " $DB.Name -ForegroundColor "Green"

  86:             $Path = "`\`\" + $Server + "`\" + $DB.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $DB.EdbFilePath.PathName.Remove(0,2)

  87:             $EdbFile = Get-ChildItem $Path

  88:             $DBSize = $EdbFile.length / 1GB

  89:             $Result = [Math]::Round($DBSize,2)

  90:             return $Result

  91:         }

  92:

  93: }

  94:

  95: $Servers = Get-MailboxServer | Select -ExpandProperty Name

  96:

  97: foreach($Server in $Servers){

  98:      $result = GetExchangeMajorVersion $Server

  99:     if($result -eq "2007"){

 100:         $is2007Clustered = get_isACluster $Server

 101:         if($is2007Clustered -eq "Clustered"){

 102:             # Get databases paths of the databases on the cluster

 103:             $DatabasesONCluster = Get-MailboxDatabase -Server $Server | Select -expandProperty Identity

 104:             foreach($entry in $DatabasesONCluster){

 105:                 get_DBSize2007Cluster $Server "$entry"

 106:             }

 107:

 108:         }elseif($is2007Clustered -eq "notClustered"){

 109:             get_DBSize2007NONCluster $Server

 110:         }

 111:     }elseif($Result -eq "2010"){

 112:         Get-MailboxDatabase -server $Server -status | select ServerName,Name,DatabaseSize

 113:     }

 114: }

Download

You can download the scripts from the following location:

[ GetEXDBPhysicalSize.ps1 – 1.3KB ]

Execution of the script is as described in the original article.

Script Description

This PowerShell script is a sample which is attached to this article.
The script performs the following functions:

• Is executed from the Exchange Management Shell
• Provides you with the physical database size of all the Exchange Databases in your environment

Download

[ GetEXDBPhysicalSize.ps1 – 1.3KB ]

Usage

Please refer to the following article:

• http://www.telnetport25.com/2012/10/quick-tip-how-can-i-get-the-physical-sizes-of-all-my-exchange-databases/

I have been doing some work recently on pulling capacity management information from Exchange 2010 using PowerShell. One requirement that I needed to satisfy was returning the physical size of all Exchange Database files within the organisation. There are a number of examples of how this can be done when you have a look around the Internet – however I found them (personally) to be a bit complex – or part of a wider script that can be hard to extract what you need from.

So I decided write my own version which can be modified to accommodate your own purposes.

The following script is a slightly modified version what I came up with for my capacity management assignment:

   1: <#

   2: .DESCRIPTION

   3:    Sample Script to demonstrate how you can get the physical Database Size

   4: .CREDITS & COPYRIGHT

   5:     2012 (c) Telnetport25.com - Released under the GNU version 3.0

   6:     Author: Andy Grogan

   7: #>

   8:

   9: Get-PSSnapin Microsoft.Exchange.* -Registered -ErrorAction SilentlyContinue | Out-Null

  10: if(!$?){

  11:     Write-Host "The Exchange Management Admin Tools are not installed on this server." -ForegroundColor Red

  12:     exit(1)

  13: }else{

  14:     Write-Host "The Exchange Management Tools are installed." -ForegroundColor Green

  15: }

  16:

  17: function get_DBSize{

  18:     param(

  19:         $DB

  20:     )

  21:     $DBnfo = Get-Mailboxdatabase -Identity $DB | Select-Object Name,Server,EDBFilePath

  22:     foreach($MBXDB in $DBnfo){

  23:

  24:         $server = $MBXDB.Server

  25:         $Path ="`\`\" + $server + "`\" + $MBXDB.EdbFilePath.DriveName.Remove(1).ToString() + "$"+ $MBXDB.EdbFilePath.PathName.Remove(0,2)

  26:         $EdbFile = Get-ChildItem $Path

  27:         $DBSize = $EdbFile.length / 1GB

  28:         $Result = [Math]::Round($DBSize,2)

  29:         return $Result

  30:     }

  31: }

  32:

  33: $MailboxDatabases = Get-MailboxDatabase | Select -ExpandProperty Name

  34:

  35: foreach($mbxDB in $MailboxDatabases){

  36:

  37:     $returnedSizes = get_DBSize $mbxDB

  38:

  39:     foreach($sizeEntry in $returnedSizes){

  40:         Write-Host "Mailbox Database: " $mbxDB -ForegroundColor Yellow

  41:         Write-Host "Size: " $sizeEntry "GB" -ForegroundColor Cyan

  42:     }

  43:

  44: }

Using the script

You can download the script above from the following location:

[ GetEXDBPhysicalSize.ps1 – 1.3KB ]

You should execute the script from an Exchange Server in your Infrastructure using the guidance that I have provided here: http://www.telnetport25.com/2012/02/quick-tip-running-exchange-based-powershell-script-files-from-the-command-line-or-a-batch-file/

Example Output

Successful execution of the script will produce output similar to that below.

The script is provided free for you to modify / use how you see fit – there are many modifications that can be made – for example:

• Port the output to HTML
• E-Mail the sizes to an administrator

I know that I have not posted here much recently (mainly down to work and publishing commitments) – but I wanted to give you folks a run down of some of the work that I have been doing for SearchExchange at the moment:

E-Zine columns

• BYOD Considerations for Exchange – http://searchexchange.techtarget.com/tutorial/BYOD-considerations-for-Exchange-admins

Ask the “Experts”

• What’s the difference between MX records and Smart Hosts? – http://searchexchange.techtarget.com/answer/Whats-the-difference-between-MX-records-and-smart-hosts
• Exchange 2010 setup error: Could not find a domain controller – http://searchexchange.techtarget.com/answer/Exchange-2010-setup-error-Could-not-find-domain-controller

Recommendations

Whereas I am a contributor to SearchExchange, that does not guarantee me any special favours. I was really “chuffed” to be number 4 on their recent "Exchange Server Blogs you need to bookmark” – there is some very distinguished company on this list – have a look at the link below – as aside from me there is some great recommended reading material.

• http://searchexchange.techtarget.com/feature/Exchange-Server-blogs-you-need-to-bookmark

There are a few things that I have let fall behind recently – for example my own personal Newsletter for telnetport25.com (if you have subscribed expect a bumper edition very soon) but I am hoping to be back in the game very soon!.

I have just migrated all of my home based e-mail to Office 365 (away from IMAP with my hosting provider). One thing that I noticed is that whilst my iPad and iPhone (using Active Sync) and Outlook 2011 (on my Mac Book) all connected perfectly using Autodiscover (as I had set this up for my domain) – I could not get Outlook 2013 Release Preview to connect and configure automatically on my Windows 8 PC.

Now is is entirely possible that this is down to some weird cock-up that I have made with the DNS configuration (although this would not explain the other Autodiscover aware clients working correctly) – but I found that the only solution was to manually configure the connection to the servers in the Microsoft Cloud.

Before I get going  – there is a KB article on the subject (for versions of Outlook from 2003 upwards) which can be found here: http://support.microsoft.com/kb/2404385/en-us which did get me into a position where Outlook 2013 would connect – but it is quite long – therefore I have provided a summary guide below:

Get your O365 Host information

In order to configure Outlook 2013 manually for Office 365, you will need to get some information first. You will need to logon to OWA via your portal account (using https://portal.microsoftonline.com) and from the “Outlook” tab click on the Help icon and selection “About” – see below:

When you have clicked on the “About” menu option you will be presented with a number of session settings relevant to your O365 account – you are interested in the “Host Address” value – see the highlighted section below:

Copy the “Host Address” value (which will be in the format of <ServerName>outlook.com)into a text editor like Windows Notepad and make the following modifications:

• Remote the https:// and /OWA elements
• Make another copy of the string that you are left with (which should be <ServerName>.outlook.com) on another line
• Change one of the values to <ServerName>.mailbox.outlook.com

See below for an example of the above:

Manually Configuring Outlook 2013 – Release Preview

Open the Mail Control Panel applet and click on the “Show Profiles” button

From the “Mail” dialog box that appears click on the “Add” button – see below

Give your profile a descriptive name and then click on the “OK” button – see below

From the “Add Account” dialog – select the “Manual setup or additional server types” radio button and then click next – see below

On the next screen ensure that the “Microsoft Exchange Server or compatible service” radio button is selected and then click “Next” – see below

On the next screen, in the “Server Settings” area – for the “Server” value – copy and paste the entry in your Notepad session which looks like <ServerName>.mailbox.outlook.com. For the User Name value – provide your Office 365 logon account which should be <some alias>@yourdomain.com. You can customise the "Offline Settings” to suite you own requirements.

When you are done – click on the “More Settings” button – see below

From the dialog box that appears click on the “Connection” tab – tick the “Connect to Microsoft Exchange using HTTP” and then click on the “Exchange Proxy Settings” button – see below

In the “Connection Settings” area – populate the proxy URL with the <ServerName>.outlook.com value from Notepad. Ensure that the “Connect using SSL only” tick box is ticked and then tick the “Only connect to proxy servers that have this principle name in their certificate”.

You will need to then provide the following principle name:

msstd:outlook.com

Tick the “On fast networks, connect using HTTP first, then connect using TCP/IP” and then change the “Proxy authentication settings” to “Basic Authentication” – see below

When you are done – click the “OK” button until you are returned to the parent “Add account” dialog box.

Click on the “Check Name” button and you will be prompted for a Username and Password – you should enter in your O365 account ID and password (this should be in UPN format of <alias>@<yourdomain.com>) and then click on the “Next” button.

You should now be able to connect to your Office 365 account from Outlook 2013.

I came back from Hol’s today to an odd issue with one of my production database copies (2010 x 3 node DAG). Whilst I was away there has been a slight incident in one of our data centres which resulted in a failover between DAG nodes. Whereas service was restored quickly – one specific database's copy failed.

My team had tried to resume the database copy and also tried to update the database copy with the delete existing files option – but each time they did, the following error message would be presented to them:

The attempt to seed database '<DB NAME>' from the active copy on server '<DBX-1>' to the copy on server '<DBX-2>' failed:

Microsoft.Exchange.Cluster.Replay.FailedToOpenBackupFileHandleException: Couldn't open backup file handle for database '<DB NAME>' to server '<DBX-1>'. Hresult: 0x50d. Error: A database backup is already in progress. Please verify that no other seeding or incremental reseeding operations are started for this database, and then try the operation again by rerunning the Update-MailboxDatabaseCopy cmdlet. 

At Microsoft.Exchange.Cluster.Replay.SafeBackupContextHandle.GetAndSetIntPtrInCER(String serverName, String dbName, String transferAddress, SafeBackupContextHandle& backupHandle)

   at Microsoft.Exchange.Cluster.Replay.EseDatabaseBackupReader.GetESEDatabaseBackupReader(String serverName, String dbName, Guid dbGuid, String transferAddress, String sourceFileToBackupFullPath, UInt32 readHintSizeBytes)

   at Microsoft.Exchange.Cluster.Replay.SeedDatabaseFileRequest.OpenSeedStreamer(Guid dbGuid, UInt32 readHintSize, Int64& initialFileSizeBytes)

   at Microsoft.Exchange.Cluster.Replay.SeedDatabaseFileRequest.Execute()

My suspicions were immediately drawn to the segment of the error ‘Couldn't open backup file handle for database’ whereas there was no specific backup software on the server, there was a Backup Exec agent. I stopped the agent on the server and then attempted the Update Mailbox command again – and this time around it the update processed correctly.

So if you should come across this scenario in your own environments, have a look at any running backups – or backup related services which might be interfering with the operation.

Script Description

This Powershell based script will install the required Windows 2008 R2 Roles and Features for Exchange 2013 (based upon the Release Preview of Exchange 2013).

This script performs the following functions:

• Asks which of the two Exchange 2013 roles that you would like to install
• Installs the relevant Windows 2008 R2 Roles and Features

• Reboots the Server after the roles have been installed

Download

[ Exchange2013RP_OSPreReq.ps1 – 1.6 KB ]

Usage

Please refer to the following article(s):

• http://www.telnetport25.com/2012/08/installing-exchange-2013release-preview-on-windows-server-2008-r2-part-1/

In the first part of this series I took you through the process of installing both the Operating System and Software pre-requisites for Exchange 2013 on Windows Server 2008 R2. In this part I would like to conclude by taking you through the (rather simple) process of installing Exchange 2013 itself.

Furthermore I would like to take you through some of the aspects of the new Exchange Administration Centre (EAC) which replaces the previous Exchange Management Console.

Installing Exchange 2013 – Video Overview

Below is the second part of my video overview series. In this part I go through how you can finalise your Exchange 2013 installation.

NOTE: The Exchange 2013 RP – can only be installed into a “green field” directory environment – e.g. It will not co-exist with Exchange 2007 or 2010 ~ so don’t try this as the install will fail with an Error: “All Exchange 2010 servers in the forest must be running Exchange 2010 SP3”.

Ok, so how do I drive this puppy?

One of the first things that you will notice is the lack of a definitive link to administer Exchange Server from within the Start Menu (see below). In Exchange 2013 the concept of the MMC based Exchange Management Console and the Web Based ECP (Exchange Control Panel) are gone.

These have been replaced with a new Web Based interface called the Exchange Administration Centre (or EAC for short). The EAC will take some getting used to for those who are used to MMC configuration in previous versions of Exchange – but those who have come from Lync backgrounds are likely to take to it well as conceptually the management concept I would say is very similar to managing Lync 2010.

The EAC is designed to allow for tighter integration between On-Premises, Online and Hybrid deployments through a single interface – as well as allow for better demarcation of roles through RBAC and simplify the deployment of the Exchange Management Tools.

But how to you access it? as it does not appear in the Start Menu!

You will need to open up Internet Explorer and type in the following: https://<yourserver>/ecp – if you would like to confirm the administrative URL’s you open the trusty Exchange Management Shell and type in:

Get-ECPVirtualDirectory | FT name,*url* –AutoSize

The output of this command should look like the following:

When you enter in the URL into your browser a page that looks like the following should open asking you to enter your Credentials:

When you have logged in you will be presented with the following:

One of the things that I like about the new EAC is that it is not “cluttered”. In previous versions of Exchange (2007 and 2010) I personally found that the MMC based interface could present you with too many options – or indeed hide the specific option that you were after in a location that did not make sense.

However, that being said – I am not completely sure at the moment if the new EAC will force more Exchange administrators towards the Exchange Management Shell (not necessarily a bad thing).

For example; I have not been able to find a means in the new Interface to “bulk create” mailboxes for existing AD accounts – which you could do in the old Exchange 2010 / 2007 MMC – but you never know it might make it into the RTM!

I have provided a very quick overview (ramble) of the Exchange 2013 EAC for your viewing below:

Sex, Drugs and Exchange 2013 Rolls

Well, perhaps not the sex and drugs (unless of course you are some kind of depraved Exchange admin that lives on the edge ~ no pun intended).

Some of the biggest news to come out in the Exchange 2013 Preview is that there are now only two Server Roles:

• Mailbox
• Client Access

The other roles (UM and HT) have been consolidated down onto one of the above (HT to CAS and UM to Mailbox).

Mailbox Server

The Mailbox Server role is the storage and UM end of business for Exchange 2013. The Mailbox role provides resilient storage for mailbox and PF data. In Exchange 2013 – whilst it maintains it key storage element and acts as an end point for client connections from the CAS servers – it also handles all Unified Messaging requests and services.

It is still important to note that the mailbox server role is only a responding end point to client requests which are proxied by the CAS Servers – no client connects directly to a mailbox server (unless, of course you have the CAS and MBX role on the same hardware – but even then none of the mailbox related services are connected to directly).

It is recommended that if you plan to split your roles out, install the Mailbox Server role first.

Client Access Server

The CAS role performs a number of functions which include (from Microsoft):

• Provides a unified namespace, authentication, and network security.
• Handles all client requests for Exchange.
• Routes requests to the correct Mailbox server.
• Proxies or redirects client requests for legacy servers, such as Exchange 2007 and Exchange 2010 Client Access.
• Enables the use of layer 4 (TCP affinity) routing – this is of particular interest as it means that Load Balancers which do not support affinity or affiliation can be used with Exchange (Windows NLB anyone?)

Perhaps one of the best new features is the last bullet point above – in essence, due to the architecture changes it does not matter which CAS you have connected to when using Outlook. One of the best explanations for this I have found is here.

Aside from the the above, the CAS servers in 2013 provide the following “Front End” Transport Services:

• Protocol level filtering Performs connection, recipient, sender, and protocol filtering
• Network protection Centralized, load-balanced egress and ingress point for the organization.
• Mailbox locator Avoids unnecessary hops by determining the best Mailbox server to deliver the message to.
• Load-balances client and application SMTP requests.

Another big change here to be aware of is that all Outlook client access is now provided via RPC over HTTP(s) – and MAPI is purely used for backend Mailbox Server communication. So if you are manually configuring mailboxes you will need to be making use of the Exchange Proxy settings within the Outlook mail control panel:

Living on the Edge – What Happened to Edge Transport?

The Edge role is not present in the release preview of Exchange 2013 where I believe the intention is to release it a little later post RTM within a Service Pack. In the interim, and certainly for the 2013 release preview you can use the Exchange 2010 SP2 Edge transport role in your environment.

Where are Public Folders in OWA?

Unfortunately the implementation for Public Folder Mailboxes for OWA was not complete at the time of the RP release – they are likely to be added within the first Service Pack for Exchange 2013.

What’s in the Tool Box?

You might also notice that on your Exchange Server, within the Start Menu under Microsoft Exchange 2013 there is an “Exchange Toolbox” entry:

At the moment this is where a number of very familiar tools live (Details Template Editor, Remove Connectivity Analyser, Queue Viewer and Tracking Log Explorer) – see below

Has Powershell changed?

Changed would perhaps be the wrong word, visually it is still the same – from from a backend point of it has been given a major overhaul as part of the Windows Management Framework v3. From a Exchange Management Shell cmdlet perspective – Exchange 2013 introduces a shed load of new commands (about 200 from what I can see) to manage your environment with.

Wrap up

I hope that you have liked this overview – and if you are hungry for more Exchange 2013 related goodness – have a look at the following sites who have been churning out some really brilliant stuff:

• http://michaelvh.wordpress.com/category/exchange-2013/
• http://exchangeserverpro.com/exchange-server-2013
• http://clintboessen.blogspot.co.uk/

There are a few guides out and about on the web about how you can install the Release Preview of Exchange 2013 on either Windows 2008 R2 or Windows Server 2012 Release Candidate. I thought that I would provide another, but instead of going through all the steps in written form – I would do a video guide and throw in a few scripts that can help speed up the process.

First off – it is important to point out that (as the name suggests) Exchange 2013 is pre-release software – and therefore steps in this guide are subject to change. You must not install Exchange 2013 into your production environment.

Prerequisites script

Before you can install Exchange 2013 RP on Windows 2008 R2, as with previous versions of Exchange you need to install a number of Operating System prerequisites.

These are detailed here http://technet.microsoft.com/en-us/library/bb691354(v=exchg.150)#WS2008R2SP1. However for convenience I have created a script which you can download below that will install them for you based upon the roles that you would like on your target Exchange Server.

You should download the script to the server on which that you will be installing Exchange 2013 RP. Before you run the script – ensure that you have followed the steps in this article to allow for its execution.

To execute the script use the command line that is highlighted in RED below – you will then be prompted to make a choice between installing the Operating System prerequisites for Mailbox Server or the Mailbox Server and Client Access Server Roles – these options are highlighted in YELLOW below:

When you have made your choice the script will being the installation process – see below;

The Powershell script above is available for download below:

[ Exchange2013RP_OSPreReq.ps1 – 1.6 KB ]

After executing the script you server will reboot so ensure that you have closed down or saved anything important.

Preparing the Server for Exchange 2013

Before we can install Exchange 2013 there are a number of pre-requisite software binaries that you need to install. These are detailed below.

1. Microsoft .NET Framework 4.5 RC
2. Windows Management Framework 3.0
3. Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
4. Microsoft Office 2010 Filter Pack 64 bit
5. Microsoft Office 2010 Filter Pack SP1 64 bit
6. Microsoft Knowledge Base article KB974405 (Windows Identity Foundation)
7. Knowledge Base article KB2619234 (Enable the Association Cookie/GUID that is used by RPC over HTTP to also be used at the RPC layer in Windows 7 and in Windows Server 2008 R2)
8. Knowledge Base article KB2533623 (Insecure library loading could allow remote code execution)

You will need to download them to a location on your intended Exchange Server.

Video Overview – Installation Process

Please click on the following video to watch the installation process of the prerequisites.

In the next part of this series, I will go through the process of installing Exchange 2013.

Click here for Part 2

Information

File Ping allows for Network Administrators to monitor the availability of network shares on a target file server – and will notify them if they go offline. This can be useful when troubleshooting Server (SVR) Service resource issues in heavily loaded environments. For more information please see the following article:

• http://www.telnetport25.com/2012/07/file-ping-for-windows-servers/

Download

[ FilePing – Version 1.0 – 676KB ]

Edit: Since I published this yesterday, I have added in a couple of new features, and integrated a full HTML Help file for the application (which can be access via the “Help” menu).

New features are:

• Option to continue trying to write the Ping File if there has been an error
• Respond to errors that have been generated in the Session Log File
• Change the colour of the Session Log file to red if there has been an error

Over the last few days I have been working on a particularly nasty issue on one of the file servers in work. The server in question is a Windows 2003 x32 Standard Edition Server box, with 2GB of RAM and practically oodles of shares which are used by both the Development and Corporate community within the organisation.

What started to happen around the middle of this week was access to mapped drives (e.g. connected to shares on the File Server) would freeze periodically. Network connectivity to the server was still available (I could both ping and RDP to the box) – but all network shares would become unavailable for anything between five to ten minutes at a time.

As time progressed throughout the day – the downtime on the shares became more and more frequent and lasting longer and longer.

Whilst this particular article is not about how I solved the issue (this may come later when I am convinced that the issues have indeed been fixed) – I found that as the nature of this problem was completely random it was tremendously difficult to know when an instance of downtime had occurred and I was completely reliant on the user community to tell me when they had “lost access”, or I would have to spend precious time clicking in and out of mapped drives on the server to see if they were still responding.

This of course, and understandably led to a lot of “teeth gnashing” and frustration for both my customers and I, as well as making it very hard to tell if any of the remediation efforts that I was making were actually improving the situation.

So, this weekend I decided that I was going to sit down and write a little tool that can be pointed at a share on a file server that will write a compact text file at a specified interval to that location and provide me with feedback on the result of the write operation.

Whilst writing the tool – it further occurred to me that others might benefit from such a program so I have decided to publish it here on telnetport25.com.

I will point out at this stage that the name “File Ping” is perhaps somewhat misleading as in the conventional sense it does not literally “Ping” anything. The context of “Ping” in the title of the application is the value of the result of the write operation performed on the target fileserver share.

Download

[ FilePing – Version 1.0.1 – 676KB ]

Installation

It is recommended that File Ping is installed on a local workstation which has the drives mapped from the remote File Server that you wish to monitor. Before you install the tool you will need to ensure that you have the Microsoft .NET Framework 3.5 present on your machine.

The tool is compatible with both x32 and x64 versions of Windows.

When you have downloaded the tool – double click on the “FilePingSetup.msi” file and then follow the on-screen prompts. At the end of the installation File Ping will be launched automatically. After install you can access the tool from your Desktop and Start Menu.

Tool Usage

The following video gives you a very quick overview of how you can use the FilePing Tool.

Recommendations

When using the tool I recommend that you setup a dedicated folder share on the target file server that will hold all of the “ping” files – this makes it easier to delete the output of the tool when you are finished monitoring.

This is a pretty well documented process on the web and indeed on TechNet, but recently I have had to change the database path within my production DAG environment, so I thought that I would share with you some of “frustrations” that I had which will give you the chance to “plan ahead” should you need to do the same.

It is important to note that nothing in this article pertains any major issues within Exchange Server 2010 – the focus is more on how prevailing conditions within your own environment (or indeed in the case of this post – conditions in mine) can affect the process of changing a DAG database path.

The process

Firstly it probably makes sense to give a high level overview of the whole process of changing the paths of DAG enabled databases – this is provided at a very high level below:

1. Backup your databases! – This might seem obvious, but it is important to ensure that you have a working backup of any database that you intend to modify.
2. Dismount the active copy of the mailbox database.
3. Remove all DAG copies of the target database.
4. Make sure that you keep the physical files (both Transaction Logs and Databases) of the database copies that you have removed.
5. Allow for – or force a Domain Replication and then refresh both the database list and copies within the Exchange Management Console.
6. From within the Exchange Management Console right click on the dismounted copy of the database and from the context menu select the “Move Database Path” option.
7. Choose a new location on your Server for the Exchange EDB path (you can also select a new location for the transaction logs if you wish to).
8. On each DAG node that will house copies of the databases move the physical files that you kept in step 4 to the relevant locations.
9. Once the database has been moved – allow for domain replication to take place (or force it if you cannot wait).
10. Mount the database.
11. Re-add your Mailbox Database copies.

For steps 2,3,6,7,10,and 11 (above) you can also use the following Exchange Management Shell commands:

Dismount-Database –id <DB ID> –Confirm:$False

Remove-MailboxDatabaseCopy –Identity <Server>\<DB> -Confirm:$False

Move-DatabasePath –Identity <DB ID> –EdbFilePath <C:\NewFolder\MyDatabase.edb>

Mount-Database –id <DB ID>

Add-MailboxDatabaseCopy –id <DB ID> –MailboxServer <Target MBX> –ActivationPreference <Act Pref>

Seems simple enough, so what can go wrong?

Well – it’s not so much what can go wrong – but what might not work as you might expect depending on how your environment is setup. The following are some considerations that I found during the migration of about 1TB’s worth of Exchange Databases to new LUNS.

Allow for domain controller replication!

When you remove the database copies or change the database path – please ensure that you have allowed for domain controller replication to have taken place. If you don’t – issues can occur during the mount process on the new path.

Furthermore – be mindful of the replication schedule – especially if your Exchange DAG nodes are in different Active Directory sites. If you are in a hurry and force a domain replication you should wait wait for it to complete. A replication should happen (from my experience) when each of the following steps have been performed:

1. Removing the database copy
2. Moving the Database path
3. Adding the mailbox copy

Also if you have a single network to a remote site that is facilitating domain controller replication, normal network traffic and DAG replication – be mindful of what time of day you are forcing increased bandwidth as you could bring communications to a grinding halt.

Log replay after the DAG copy has been re-added

Depending on how long your databases are dismounted and how busy your environment is, replaying logs can take quite a while to complete. This will also be dependant on the speed of the network connection which your replication network has access to between DAG nodes. If you have a configuration which is similar to that of my company – where the replication network is in essence a remote link to another data centre that carries other traffic then you need to factor this into you time calculations.

Perform the changes outside hours

This is perhaps one of the more obvious recommendations – but honestly please stick to it!. Unless you have configured dedicated NIC for replication, on a dedicated VLAN, on a dedicated network pipe to a remote datacentre which has your remote Exchange Servers – attempting to compete for bandwidth on the link with day-to-day traffic is a “no no” and will prolong the process.

Restart the MSExchangeSearch Service when the move has completed

Whereas not always necessary, I have seen a few instances where the Content Index Catalogue from the previous database maintains a lock with the MSExchangeSearch service. Restarting the Service will release the lock and allow for the files to be deleted.

Activating Copies after the process

When the database path has been moved – the MSExchangeSearch will resume crawling the database. During this process – there is a chance that the copy will not activate until the crawl has completed on the relevant Exchange Server. I recommend that you keep an eye on the indexing status to ensure that it reads as “Healthy”. You can do this using the following command on the server(s) which have a database copy:

Get-MailboxDatabaseCopyStatus | select Name,*ContentindexS* | ft –AutoSize

When everything is ok, you should receive output similar to that below:

Do not work on two or more databases at the same time!

This might sound a little mad, but I would recommend that you only work on one database at a time if you are moving multiple databases to a new path. The various Services in Exchange will be doing lots of different things – therefore do not overload them.

In fact there are some operations that cannot happen on multiple databases at the same time.

Other Options

You you could opt to not move the physical database path, and choose to create a new database, establish a copy and then move all the mailboxes, however – whilst this does get around replay and indexing issues – it does not necessarily protect you from excessive transaction log generation, which could create more problems that it solves – unless you are prepared to place the databases in Circular Logging mode, or are not worried about the amount of logs which might be generated.

However if you are looking at a DB with a small amount of Mailboxes – this may be a good choice.