Back in May 2013, we discussed an issue which caused the Hyper-V Did Not Find Virtual Machines To Import error.  Well, as mentioned in that blog post there are a few reasons for this error message being displayed and it does depend on the versions of Hyper-V in use.

There were some comments posted (thanks again for that by the way!) which mentioned an issue with importing VMs into Windows Server 2012 R2 and Windows 8.1.  I thought it may be worth bubbling this up again now that Windows 8.1 is available and people may be running into the same import issue.  Ideally we can raise awareness so that we can plan the right approach.

The issue is that VMs which were previously exported from Windows Server 2008 or Windows Server 2008 R2 Hyper-V cannot be imported into Windows Server 2012 R2 Hyper-V and Windows 8.1.   Please note that the same  VMs could be imported into Windows Server 2012 Hyper-V  (note the missing R2 there) without any issue.

Update 2-12-2013: Added new post to walk through the conversion process using Server 2012.

Let’s take a peek at the issue, and then discuss what we can do!

Importing Windows 2008 R2 Hyper-V VM Into Windows 8.1

For the purposes of this post, let’s try and import a VM called AD1HC1.  This was successfully exported from Windows Server 2008 R2 Hyper-V.  Currently this VM and all its associated files reside in the G:\VMs\AD1HC1 folder.  The various files can be seen here:

There are no hidden tricks and this is an exported VM that can be imported to Windows Server 2008 R2 without issues, and has been many times.

If we use the GUI and try to import the VM into Windows 8.1

We get the following error:

Hyper-V did not find virtual machines to import from location ‘G:\VMs\AD1HC1’

When reviewing what Process Monitor sees on the file system, there are no Access Denied error messages.  We are able to read the disk and review the files contained within.

If the files exist on the disk and we can read them, what’s up then?  For the eagle eyed out there, you may be wondering why the .exp file has not been read…..

Digging In

If you wrote scripts to import/export Windows Server 2008 Hyper-V VMs, there is a small clue in the Hyper-V section located in the Features Removed or Deprecated in Windows Server 2012 page on TechNet.   **

• VM Chimney (also called TCP Offload) has been removed. The TCP chimney will not be available to guest operating systems.
• Support for Static VMQ has been removed. Drivers using NDIS 6.3 will automatically access Dynamic VMQ capabilities that are new in Windows Server 2012.

• The WMI root\virtualization namespace is deprecated. The new namespace is root\virtualization\v2.

• Windows Authorization Manager (AzMan) is deprecated. You may need to use new management tools for virtual machines or redesign the authorization model.

And if we then look at the same section in the Features Removed or Deprecated in Windows Server 2012 R2

• WMI root\virtualization namespace v1 (used in Hyper-V)

So the WMI v1 namespace was deprecated in Windows Server 2012, and then removed in Windows Server 2012 R2.   Why is this important?  When the Export call was made to export the VM from Windows 2008 R2, the WMI v1 namespace was used.  This can be seen with a PowerShell snippet  which binds to the Hyper-V WMI Namespace.

$VMManagementService = Get-WmiObject -Namespace root\virtualization -Class Msvm_VirtualSystemManagementService -ComputerName $HyperVHost

In a post on the Hyper-V TechNet forum there are some details worth reading from Taylor Brown, and if you don't already read his blog the RSS feed is here.

VM's that are exported from Windows Server 2008 or 2008 R2 utilized the version 1 WMI namespace which resulted in an .exp file to represent the exported virtual machine. In Windows Server 2012 we introduced a new WMI namespace (version 2 or root\virtualization\v2) which implemented a much better import/export model – allowing you to effectively just copy the virtual machine folder (with the VM’s XML configuration file inside it) as well as the VM’s VHDs and then import that directly. For Windows Server 2012 we maintained the version 1 WMI namespace which allowed for importing of Windows Server 2008/R2 VM’s on 2012.

In Windows Server 2012 R2 we have removed the old version 1 namespace which means we can’t import virtual machines that where exported from Windows Server 2008/R2.

What To Do

As you can see, VMs that were exported from Windows Server 2008 & 2008 R2 cannot be imported as-is into Windows Server 2012 R2 or Windows 8.1.

Don’t Panic Captain Mainwaring, Don’t panic!   ***

Don’t panic as there are options!!  Let’s look at them based on the scenario.  There are two basic takes on this:

1. Original Hyper-V Server and the VM is still available
2. Original Hyper-V Server is not available

Original Hyper-V Server & VMs Available

If you exported from Windows Server 2008 or 2008 R2, and the original host is still available with the VMs then probably the easiest option will be to get the VMs off that machine in a format that is easily importable to Hyper-V 2012 R2.

On the original Hyper-V server, power down the VMs.  Once they have shut down, then stop the Hyper-V Virtual Machine Management Service (VMMS).  This will unlock the VM’s files.  Simply copy over the VM folders to the Windows Server 2012 R2 server and they can be imported.  Remember this was one of the features added to Windows Server 2012 - we do not have to specifically export a VM before it can be imported.  Funnily enough this functionality was added in the WMI v2 namespace for Hyper-V….

Original Hyper-V Server Unavailable

If the original server or a copy of the VMs is no longer available, there are still a couple of options.  This may be the scenario if you are re-purposing the hardware and the original machine has been wiped, or if these are archived lab VMs that you are trying to import to a new version of Hyper-V.

Perform Intermediate Import

If, and this will not apply to everyone, you have a Windows Server 2012 Hyper-V machine, the 2008 / 2008 R2 VMs can be imported to that server.  Note that this is not a R2 2012 server. Since 2012 still has the WMI v1 namespace (albeit deprecated), we can import the .exp machines.  Once successfully imported to 2012, the VMs can be exported or copied over to Windows Server 2012 R2.  You do not need to power on the VMs after importing them to the intermediate Windows Server 2012 machine, that server is only used to perform the import thus allowing the VM to be copied to Windows Server 2012 R2.

Travis mentioned an interesting take on this in the comments below.  Consider a temporary boot to VHD option just to get the necessary import step done.  Thanks Travis!  Would love to know if that helps folks out at all – please post a comment below!

Update 2-12-2013: Added a How To on this topic.  Please see this post.

Create New VM – Reuse Virtual Hard Disk

If the above method is not available, or is too time consuming, an option is to create new VM configuration and specify to use an existing virtual hard disk.  By doing so we can re-use the VM’s virtual hard disk file.  Since the virtual NIC now has a different GUID Windows will recognise it as a different NIC, and you will need to re-enter the IP address in the VM.

Cheers,

Rhoderick

** – What is the etymology of the word deprecated? – and Wikipedia doesn’t count!  Personally I prefer depreciate since the original Latin dēprecātus was to pray.

*** – If you have not seen the classic BBC comedy Dad’s Army take a look!

>>>

Previously Windows 8.1 and Windows Server 2012 R2 were released to the TechNet subscriber download centre.   Prior to Windows Server 2012 R2 being tested and validated by the Exchange Product Group, we had asked to pause deployments of 2012 R2 DCs into environments where Exchange was installed. 

Exchange 2013 Service Pack 1, Exchange 2010 SP3 RU5 and Exchange 2007 SP3 RU13 were all released today, the 25th of February 2014.   As announced back in November the Exchange team were working to test and validate Exchange against Windows Server 2012 DCs.   That work has been completed, and the support stance has been updated on TechNet. 

To prevent confusion for folks that may have read this post prior to today’s updated support stance it has been heavily edited to reflect the new information.  Probably not much point showing out-dated stuff, eh?

Walking The Supported Path

TechNet documents the Exchange Product Group’s supported OS for each version of Exchange.  Here are the links for your convenience:

There have been a couple of posts in the TechNet forums where people have run into some issues when they have either:

• Upgraded the OS in place to Windows Server 2012 R2
• Tried to install Exchange 2010  onto Windows Server 2012 R2

Unfortunately there is not much that can be done to help apart from digging out backups as they are not supported options.

I didn’t list Exchange 2003 as hopefully no one out there is going to be trying that with Server 2012 R2. **

Supported Operating System Platforms

The following tableidentifies the operating system platforms on which each version of Exchange can run. Supported platforms are identified by an X character.

You will note that Windows Server 2012 R2 is currently only listed as a supported OS platform for Exchange 2013 SP1.  In addition to this please also note that Windows Server 2012 R2 is listed as a supported Domain Controller for Exchange 2013 SP1, Exchange 2010 SP3 RU5 and Exchange 2007 SP3 RU13 or later builds of each. 

Supported Active Directory Environments

The following tableidentifies the Active Directory environments with which each version of Exchange can communicate. Supported environments are identified by an X character. An Active Directory server refers to both writable global catalog servers and to writable domain controllers. Read-only global catalog servers and read-only domain controllers aren't supported.

Previous update history to this post for full disclosure:

Update  3-10-2013: Added additional note about Domain Controller support

Update 12-11-2013: Added note to indicate TechNet has updated support stance to say Exchange 2013 support  for Windows Server 2012 R2 will be provided by future version of Exchange 2013.

Update 20-11-2013:  Additional details here.

Update 25-2-2014:  Re-wrote this post to reflect the current support stance

Cheers,

Rhoderick

** Well you never know I suppose….

>>>>

When discussing and reviewing Office 365 with customers, I wanted to have a series of posts to illustrate the steps involved when deploying Office 365.   In the burgeoning drafts folder ADFS was at the top, so that got finished first!

The act of deploying and configuring ADFS 2012 R2 for Office 365 will be broken down into three separate blog posts

1. Install ADFS (this post)
2. Install ADFS Proxy
3. Leverage ADFS with Office 365

Identity, Identity, Identity

The IT security landscape keeps evolving.  One of the recent changes is a move away from ACLs on files in the NTFS file system to an access control system that is based on claims.  Claims based authentication is an industry standard security protocol to authenticate users.  This is the underlying WS-* standards that describe the usage of Security Assertion Mark-up Language (SAML) tokens.  Claims based auth requires these tokens, and by extension an entity that can issue the token.  This is the Secure Token Service (STS).  The STS server can be based on Active Directory Federation Services (ADFS) or other platforms that provide this service.

ADFS lights up one of the three options for Office 365 identity management, which is option #3 in the below list:

1. Cloud Identity – users are created, and managed,  in Windows Azure Active Directory (WAAD).  No connection to any other directory.  This is the simplest model as there is no integration to any other directory.  Each user has an account created in the cloud which does not synchronise anywhere else.  Note that you will still typically need additional on-premises credentials to gain access to a local workstation and local resources.
2. Directory Synchronisation – Users are created and managed in the on-premises directory and get synchronised up to Office 365 so they can access Office 365 resources.  Typically this means running the DirSync appliance, or in some cases FIM with the Windows Azure Active Directory Connector.  The newer builds of DirSync allow for the user’s password hash to be synchronised up to Office 365.  Note this does not say clear text password.    This allows user’s to logon to Office 365 using the same credentials as on-premises with no additional infrastructure.
3. Federated Identity – Federation relies on directory synchronisation so that WAAD is populated.  When the authentication request is presented to Office 365, the service will then contact the on-premises ADFS infrastructure so that AD is responsible for authenticating the request.

ADFS is the primary choice for customers who want to use federated identities with Office 365.  In addition to this there are a variety of qualified third party identity providers that can be connected with Office 365 to provide the necessary plumbing for federation.  The shortcut URL aka.ms/SSOProviders  links to the ‘Works With Office 365’ Identity program, and lists the identity providers that have been qualified with Office 365.  Please read the notes on the TechNet page with regards to the testing and support aspects of these services.

Some customers will use these services as they do not wish to invest in a fault tolerant and geographically dispersed ADFS implementation.  The availability of ADFS is a key discussion point when discussing federation.  For whatever reason if the ADFS infrastructure is unavailable, then Office 365 cannot complete the authentication process and thus users cannot get access to Office 365.

In addition since DirSync now replicates the user’s hashed password to WAAD, some customers now use DirSync to provide Same Sign On / Single Sign On (SSO).  DirSync version 1.0.6385.12, which was released in May 2013, and latter builds provide the ability to synchronise passwords.  DirSync can be downloaded here, and the TechNet Wiki has details on the release history.   When running the configuration wizard with this release you will get the shiny “Password Synchronization” window:

This is worthwhile to mention as there is still a perception that ADFS is a hard requirement to get SSO.  That is soooooooooooo  Q1 2013!

Anyway, I digress let’s get back to ADFS…..

We shall look at installing ADFS 2012 R2 since there are numerous compelling features in this release!

What’s New And Improved In ADFS 2012 R2

The quick answer is a lot!  Some examples include:

• IIS dependency removed
• Single server installation option removed and now have single farm install (recommended to install a farm always in prior release anyway)
• Separate ADFS proxy role removed.  ADFS proxy now based off Web Application Proxy (WAP), and is used to publish the ADFS server to the Internet.  WAP can publish many other applications, not just ADFS.
• ADFS extranet lockout – ADDS account lockout protection on the ADFS proxy
• Access control based on network location to control user authentication to ADFS

There are many others, but check here for them since we are focussing on Office 365 usage for ADFS.

Note that you will not see me  call this release ADFS 3.0.  Its full and proper name is  ADFS 2012 R2.  for reference here are the older versions and what some folks call them:

Update 5-5-2014:    Please also see this post on exploring ADFS 2012 R2 Extranet Lockout protection. 

Update 29-5-2014:  Please also review update 2948086 Update that improves AD FS proxy and STS reliability in Windows Server 2012 R2 when multiple clients sign in.

Update 9-9-2014:    For the other posts on ADFS, please view this tag cloud.

Planning And Prerequisites, And Other Fun Details

Prerequisites

The prerequisites are listed on TechNet.  Of course before jumping into the install the installation needs to be planned.

ADFS Role Planning

The ADFS role should be deployed within the corporate network, and not in the DMZ.  The ADFS proxy role is intended to be installed into the DMZ.

The default topology for Active Directory Federation Services (AD FS) is a federation server farm, using the Windows Internal Database (WID), that consists of up to five federation servers hosting your organization’s Federation Service. In this topology, AD FS uses WID as the store for the AD FS configuration database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.

Since the availability of Office 365 relies upon the availability of ADFS when the domain is federated there is a strong recommendation to have at least two ADFS servers with a redundant ADFS proxy infrastructure.

Please review the design guidance on TechNet.

ADFS Service Account

We can now use a standard service account or a Group Managed Service Account in ADFS 2012 R2.

In this case since the KDS root key was not configured, lets leverage a standard service account.

The installation process should set the required Service Principal Names (SPN) on the account.

ADFS Namespace

Select what name you are to use to access ADFS.  Typically this is along the lines of:

sts.wingtiptoys.ca

adfs.tailspintoys.ca

Note that this is the namespace for the ADFS service.  Since we will be using Kerberos to access ADFS internally, there must be a Service Principle Name (SPN) registered for this name.  This will be associated to the service account, and since SPNs operate in the “Highlander – there can be only one!” mode you do not want to duplicate the SPN on the ADFS server by naming the computer the same as the ADFS namespace.

You also want to discuss what display name should be chosen, as this will be visible to users.

Certificates

Since ADFS leverages SSL, we need to have a SSL certificate.  You could try three options, but only one will work:

1. Self-signed certificate
2. Certificate issued from internal PKI
3. Certificate from 3rd party public CA

Office 365 needs to see a valid Service Communication Certificate on your ADFS infrastructure, so you are going to have to buy a certificate from a public CA.  Office 365 will not trust a service communication certificate that is either self-signed or from your internal CA, which results in tears.  We can use self-signed certificates for the Token Decrypting and Token Signing Certificate.  These are separate from the service communication cert.

Please follow the documentation from your chosen CA to request, install and complete the certificate.  The steps required vary from vendor to vendor and also over time.  Make sure you are not missing any updated intermediate certificates!  How would you know?  Follow their  process!!

For the purposes of this post we shall deploy the initial ADFS server, and in the future add another ADFS server for redundancy.

Installing ADFS On Windows Server 2012 R2

After starting up server manager’s add roles and features wizard, select Active Directory Federation Services, then click next. 

We don’t need to add any additional features.  Remember that the IIS dependency was removed in ADFS 2012 R2.

Clicking next takes us to the ADFS splash screen.  Note that it helpfully tells us that the specific ADFS proxy role has been removed in Windows 2012 R2 and how to go about installing it.  Shame I missed that the very first time  I ran this, and could not find the old school ADFS Proxy role…

Clicking next will then install the necessary bits.

Bits are being shuffled around…

Shuffling has been completed, and the installation is complete.   You can launch the ADFS configuration wizard from here, or alternatively if this window is closed it can be launched from server manager.

Before starting the ADFS configuration wizard I already installed my 3rd party certificate and tested that is was correctly installed.

Additionally a service account called ADFS-Service  was also pre-created.

The wizard also states that you must have access to Domain Admin (DA) credentials!

Note that you are only given an option to either make a new ADFS farm or add this box to an existing farm.  This saves the painful issue from older ADFS builds, where ADFS was not installed into a farm you were then unable to easily the add the second ADFS server for redundancy.

Provide your domain admin credentials.

We need to select the SSL certificate that we will use and also provide the ADFS name we selected in the design process.

In this case the name is adfs.tailspintoys.ca   -- note that there is no concept of an InternalURL or ExternalURL for the ADFS namespace.  Clients will use the same name on the intranet and internet to locate ADFS.  Thus split DNS will make life simple!

Provide your chosen display name, and click next.

As mentioned earlier it is possible to use a GMSA as the ADFS service account.  GMSA will automatically update the service account’s credentials and administrators will also be oblivious as to its password.

In this case a standard service account was used.

Select the database configuration as per the design.

The Tailspintoys corporation will use WID.

Review the options, and when happy pull the trigger!

For reference the PowerShell script is shown here:

#
# Windows PowerShell script for AD FS Deployment
#

Import-Module ADFS

# Get the credential used for the federation service account
$serviceAccountCredential = Get-Credential -Message "Enter the credential for the Federation Service Account."

Install-AdfsFarm `
-CertificateThumbprint:"5804746A7980C8682FBF408D48EF6C3B02A5ZORG" `
-FederationServiceDisplayName:"Tailspintoys STS" `
-FederationServiceName:"adfs.Tailspintoys.ca" `
-ServiceAccountCredential:$serviceAccountCredential

The ADFS pre-requisite checks are done, and we can proceed to the configuration:

One coffee later, we have a shiny new ADFS server – whoo!!

We are not quite done yet, and there a couple of additional things to do!

Next Steps

ADFS Update(s)

Update 29-5-2014:  Please also review update 2948086 Update that improves AD FS proxy and STS reliability in Windows Server 2012 R2 when multiple clients sign in.

Update 11-12-2014:  The above update 2948086  is now bundled in this rollup: May 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

Update 16-7-2014:  Other updates you may want to review are at the bottom of this post.

When multiple clients (over 200 clients) try to sign in by using an Active Directory Federation Services (AD FS) proxy, the AD FS proxy consumes 100% usage of the CPU. In this situation, the AD FS proxy performance is slow, and causes a delay that exceeds 10seconds. This also causes STS to work under minimal load. Therefore, STS rejects the requests or serves only 5 to 10 requests per second.

DNS A Record

We must create the DNS record  for the ADFS instance.  This maps to the ADFS namespace that we previously planned.  Create this A record in your internal DNS infrastructure.

Once the DNS record has been created an propagated ensure that it resolves correctly.

One thing to mention here, if you create a CNAME and point that to the server hosting ADFS chances are that you will run into a never ending authentication prompt situation.

In the below example the ADFS namespace is called adfs.tailspintoys.ca and a CNAME was used to direct traffic to the ADFS server called tail-ca-sts.tailspintoys.ca.    This will likely cause the client to obtain a Kerberos ticket for the incorrect name.

The easiest way to stop this is to use  a regular A record, like so:

There is also an option contained in KB 911149  that some folks have mentioned.

Additional Steps

This topic covers additional steps to configure AD FS after you install the first federation server, including:

• Opening the ADFS Management Snap-in
• Configuring Name Resolution for AD FS Services
• Adding nodes to the farm
• Adding a Web Application Proxy
• Enabling Device Registration Service

For more information about how to deploy AD FS, see How to deploy AD FS in Windows Server 2012 R2.

Verify Federation Service Metadata

Open Internet Explorer and navigate to your ADFS server’s federation metadata URL.

This will be something like the below, just change the FQDN to match your environment.

https://adfs.tailspintoys.ca/federationmetadata/2007-06/federationmetadata.xml

https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml

The result should show this:

Verify ADFS Sign-In Page

Browse to the ADFS sign-in page and test that you are able to authenticate.

The URL will be similar to the below, again change the FQDN to match your organisation’s.

https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm

https://sts.contoso.com/adfs/ls/idpinitiatedsignon.htm

You should see the below, and be prompted to sign in:

Depending upon how IE is configured you will either be prompted to provide credentials or be automatically signed-in.

If you want to have users be automatically signed-in then configure your browser settings to trust the federation server role by adding your federation service name (for example, https://adfs.tailspintoys.ca) to the browser’s local intranet zone. This will enable seamless sign-in using Windows Integrated Authentication.

Once we are happy that the ADFS instance is functioning appropriately we can then move onto installing the ADFS proxy role.

This will be covered in a separate post, to prevent this one getting too long!

Cheers,

Rhoderick

Back with the first few releases of Exchange, product updates were made available via service packs.  This continued into the Exchange 2000 and Exchange 2003 days.  It seems like an eternity ago, and dinosaurs were still roaming the Earth, when Exchange 2003 SP2 was released in October of 2005 as a whopping 109 MB download.

Exchange 2007 moved to a different servicing strategy which added a predictive scheduling element to the underlying Service Pack cycle so customers had a vehicle to receive fixes faster than wait for the next service pack.  Exchange 2010 does the same.  These updates that we speak of are the Update Rollups, Rollups, URs or RUs.

One issue with this though is that Exchange 2007/2010 tools show the currently installed Service Pack version, as they did in Exchange 2003, and not what RU is currently installed.  So when you look at the below screenshot of an Exchange 2010 organisation you can see that it is running SP2 as the build is 14.2 but you cannot state what RU is currently installed.  If service pack 3 was installed then the build would start with14.3.

And the same information is mirrored in the GUI:

How can we find out what RU is currently installed?

The simplest way we can check it to look for installed updates in Add/Remove programs (or whatever it’s called nowadays)

Or by going help –> About in the Exchange Management Console.

Note that the Help –> About method does not give you a text based description of the installed RU, and a link to the relevant KB article.  We need to use the techniques described below to map the build information to the released products.

Well, that’s ok but you can do better…

Tom Kern originally addressed this back in 2010 with his post to the Exchange team blog.  As with Exchange 2003 checking the version of key files is a great way to determine the current build of Exchange.  As an added bonus this can be automated and scripted.  Party on Wayne!

In its simplest form Tom demonstrates how to check the version of Exsetup.exe locally on a server:

GCM Exsetup.exe | % {$_.FileVersionInfo}

Expanding this out, '”GCM”  is an alias of Get-Command and “%” is an alias to ForEach-Object,  which then retrieves the FileVersionInfo attribute of the file passed down the pipeline which is Exsetup.exe.  So this could be written out fully as follows:

Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}

To prove they are aliases run Get-Alias GCM  and review the output. You also may be thinking about the location of Exsetup.exe and why this is not specified in the above command.  This is because Exchange setup adds the Exchange \bin folder to the path environment variable.  To check this out in PowerShell we can use:

Get-Item ENV:Path | FL

Taking a sidebar, we can use the same technique to show the version information of all the .exe files in the C:\Windows folder:

Dir C:\Windows *.exe | GCM | % {$_.FileVersionInfo} | FT -AutoSize

As Tom mentions, you then correlate the exsetup.exe version number you find with those listed in Exchange Server 2007: Platforms, Editions, and Versions, Build numbers and release dates for Exchange Server or on the actual rollup update download pages.   The content in that KB is a little stale, and chances are you want to take a look at Exchange Server and Update Rollups Build Numbers on the TechNet Wiki.

So looking at the Exsetup.exe version on a lab server:

We can see that version 14.2.309.2 is Exchange 2010 SP2 RU3.

Well, that’s better but I want more

We can now get a local server’s build, but what about remote machines and checking the entire organisation?  Scripting to the rescue!  As with most things scripting there are a few different ways to achieve the same result.  Bhargav has a script on his blog to determine the build version information using remote registry and also Get-Content.

As an alternative, if you have WinRM Remoting enabled you can then use the Invoke-Command cmdlet to remotely access servers if they have the necessary build of WinRM, PowerShell and .Net Framework. Exchange 2010 servers already have the necessary components installed as the underlying prerequisites to install Exchange 2010 include NET Framework 3.51, PowerShell 2.0 and Windows Remote Management (WinRM) 2.0.  These prerequisites can be installed easily by Exchange 2010 setup, using a feature introduced by Exchange 2010 SP1.

Sample code to illustrate getting the Exchange version using PowerShell remoting:

Update 5-11-2013:  Updated ForEach loop

$ExchangeServers = Get-ExchangeServer  | Sort-Object Name

ForEach  ($Server in $ExchangeServers)
{

Invoke-Command -ComputerName $Server.Name -ScriptBlock {Get-Command  Exsetup.exe | ForEach-Object {$_.FileversionInfo}}

}

Note that the Invoke-Command is a single line that may be displayed on multiple lines due to word wrapping.

One other thing that is good to discuss is a detail around ForEach  and ForEach-Object.  Be sure to avoid confusing the ForEach keyword with the ForEach-Object cmdlet.   If that is done then the above code will fail to run and you will get this error:

Unexpected token 'in' in expression or statement

Back to Powershell remoting now!

Note that it did say *IF* you have WinRM Remoting enabled above.  If this is not the case then you will likely see this lovely error which will no doubt brighten up your day!

Connecting to remote server failed with the following error message : The WinRM client cannot complete   the operation within the time specified. Check if the machine name is valid and is reachable over the network and fire wall exception for Windows Remote Management service is enabled. For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionStateBroken

To quickly check to see the configuration of WinRM:

Winrm enumerate winrm/config/listener

If enabled you should see something similar to this:

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 10.0.2.11, 127.0.0.1, 169.254.1.65, 192.168.2.11, ::1

If there is currently no listener, then use Enable-PSRemoting  or  the winrm quickconfig command.

Note that in WinRM 2.0 and newer the listener is created on port 5985 TCP for HTTP and HTTPS is port 5986 TCP.  To Configure WINRM for HTTPS the winrm command can changed to:

winrm quickconfig -transport:https

To configure a HTTPS listener via PowerShell, specify the –UseSSL parameter on the Set-WSManQuickConfig cmdlet.

For more fun and games that you can have with PowerShell remoting, please see:

Running Remote Commands

about_Remote_Requirements 

Well, that’s great but I want it all

Chances are that you don’t fancy logging on to each server and running Enable-PSRemoting.  If that does excite you, then you need help!  For the others who want to save time and ensure a consistent management strategy is applied to all of their servers then we can enable and configure PowerShell remoting using Group Policy.

Leaving on a happy thought, this issue is resolved in Exchange 2013.  When Cumulative Updates (CUs) are installed on an Exchange 2013 server the version information displayed will be updated to reflect the update.

The Exchange 2013 build numbers are also documented on the TechNet wiki.

Cheers,

Rhoderick

>>>

From time to time we need to see how our Exchange databases are doing so that they are being managed proactively.  One aspect is tracking size and the utilization of each database.  At the simplest level we want to ensure that the database and transaction log LUNs do not run out of disk space.  That would be bad.

Sometimes we want to take a peek at the database, and check that the size of the database is within design expectations.  We can look at the amount of user data stored in the database, system usage for recoverable items in addition to looking at the size of the database on disk.  Some folks also want to see the blank space that is within a database.  This blank space is sometimes called:

• Available Mailbox Space
• White space
• Free database pages
• Free space

Historical Approach To Checking White Space

In ye olden days when Exchange admins went to work on horses (alright, iron horses), we would look for the venerable application event log entry 1221.  This event would tell us the amount of white space within the database.  This event was introduced in Exchange 5.5 SP1 back in August 1998.  That’s more than 15 years ago, eeek!!   

In those simple Exchange days we would have one Public Folder (pub.edb) and one Mailbox database (priv.edb) per server.  Standard Edition could have a database of up to 16GB, and Enterprise had the “unlimited” database.  This was before the advent of the .stm file so all content lived in the .edb file.  Event ID 1221 would then report on the white space contained within the database file.  Life was indeed simple and good! Additionally Exchange 5.5 SP1 also added a second enhancement for determining white space which was the ESEUTIL /MS switch to dump out the space consumed by tables in the database.  More on this later….

As mentioned in the KB, the free space that is reported by Event 1221 is a conservative estimate. If you perform offline defragmentation, you will recover at least the amount of space that is reported as free. All space in an Exchange database is owned either by the database root or by particular tables in the database. Event 1221 estimates free space by calculating the number of empty pages owned by the messages table, the attachments table, and the database root. Free pages that are owned by other tables in the database are not taken into account.

Things advanced, the dotcom bubble popped and with the advent of Exchange 2000 the streaming file was introduced.  The intent was to store native RFC content in the streaming file as the Internet was the future and content would be converted between the .stm and .edb as needed.  Event 1221 does not review this shiny streaming thingymabob, and did not report what free space may have been available within the .stm file.  For a trip down memory lane there is an excellent read in this document Determining the True Amount of Space in an Exchange Database

If ESEUTIL /D was executed against a database the .stm would have been defragmented in addition to the .edb by default.  Though this could be changed by specifying the /I switch.     Details on defragmenting databases are can be found in this KB.

Exchange 2007 dropped the .stm file and just like Atomic Kitten, the .edb became whole again.  Event 1221 was still with us and reporting on the database white space!

Then along came Exchange 2010, sans Event ID 1221….

Getting White Space In Exchange 2010

Exchange 2010 introduced numerous improvements to the Mailbox role.  These improvements included things like

• Enhanced ESE physical store to improve performance
• Larger 32 Kb ESE page size
• Dumpster 2.0
• No database level attachment table
• Updated Online Maintenance routines

As part of the changes to the mailbox role, the venerable event ID 1221 was removed, and output was added to Get-MailboxDatabase called AvailableNewMailboxSpace.  This data is returned when the –Status parameter is also specified to execute the more expensive work items.  We can see the difference below, note the second command has –Status added:

So NewAvailableMailboxSpace looks good?  Well not so much.  This parameter only looks at the root portion of the database.  This is clearly stated in the Exchange team blog post.  For reference the relevant text is shown below.

Remember we would come back to ESEUTIL /MS? 

We need to use ESEUTIL /MS to get an accurate picture of white space in an Exchange 2010 database. 

Running ESEUTIL /MS against a lab database shows the following:

From this we can see the breakdown in the database structure and where space is being consumed.  Note that this can only be executed against a dismounted database, and you will receive the following error if running against an active mailbox:

Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use)

And if you are thinking that I’ll be sneaky and run it on a passive database copy in a DAG, then you will receive this error instead, after stopping the replication service else you will get the same error as listed above:

Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was not shutdown cleanly. Recovery must first be run to properly complete database operations for the previous shutdown.)

Conclusion

To get an accurate representation of the amount of white space in an Exchange 2010 database we need to use ESEUTIL /MS.    Note that the database must be dismounted, else you will receive JET errors and no data will be returned. 

Dumping out the table information is a fairly quick operation, unless the verbose /V option is used and then the time taken will greatly increase. 

How often do I expect this to be used?  Rarely and typically as part of troubleshooting.

The days of online maintenance killing itself trying to defragment partially filled 4K pages of data to be on a single ESE page are gone.  The same goes for offline defragmentation.  We now live in a world where large mailboxes are the norm and any white space will be quickly re-used.  Also consider that many organisations are now running 24 * 7, and it is hard to justify the impact caused by taking a database offline. 

Defragmenting databases to reclaim whitespace should be a rare event nowadays.  Exchange 2010/2013 are designed to use larger and cheaper storage which means you can get more storage capacity for the same price point.  Rather than defragmenting databases we should look to leverage the online mailbox move experience in Exchange 2010/2013 and simply move mailboxes to a new database and then discard the original one.  This is critical when we are discussing DAG replicated databases. 

Cheers,

Rhoderick

>