Link to the updated Hyper-V poster for 2008 R2 SP1 is here.
This poster provides a visual reference for understanding key Hyper-V technologies in Windows Server 2008 R2 Service Pack 1. It focuses on architecture, snapshots, live migration, virtual networking, storage, RemoteFX and Dynamic Memory. You can use this poster in conjunction with the previously published Windows Server 2008 Hyper-v Component Architecture, Windows Server 2008 and Windows Server 2008 R2 component posters.
This poster has been updated for Windows Server 2008 R2 Service Pack 1 with Dynamic Memory and RemoteFX.
Cheers,
Rhoderick
These are oldies but goodies. Posting links as requested.
Update: I Created a Deep Zoom of the posters so that it is easy to scroll around in a browser or mobile device. Click the toggle button at the bottom right hand corner to enter full screen mode.
Downloadable from here.
As a bonus, the Exchange 2007 Component Poster can also be downloaded.
Last week the Exchange team released SP2 for Exchange 2010 over on the Exchange team blog as described in the previous post which announced the upcoming release.
I wanted to use this blog entry to provide links to all the relevant content for SP2 and to raise awareness of some specific issues so that they will not negatively impact your deployments.
You may have heard of the four main features that are included in SP2
While these are great additions in functionality over and above the other issues fixed with the service pack, please enjoy the service pack responsibly!
What do I mean by that? Well, you need to ensure that you are fully informed about the caveats with the service pack and are aware of all of the changes that it will make within your environment. Additionally you will need to test the service pack in your lab which is representative of your production environment. Third party software vendors should also be consulted to ensure that they are in a position to support Exchange 2010 SP2 as you do not want to rush out and install SP2, run into an issue, and then discover that vendor X does not currently support their product when running with Exchange 2010 SP2. That would be called a RGE (Resume Generating Event).
To read up on the full details of what is contained within the service pack please carefully read the following.
What's New in Exchange 2010 SP2
http://technet.microsoft.com/en-us/library/hh529924.aspx
Exchange 2010 Release Notes
http://technet.microsoft.com/en-us/library/hh529928.aspx
Issues That Are Fixed in Exchange 2010 SP2
http://technet.microsoft.com/en-us/library/hh672189.aspx
Multi-Tenancy and Hosting Guidance for Exchange 2010 SP2
http://www.microsoft.com/download/en/details.aspx?id=28192
Exchange 2010 SP2 Build Of ExMon (Exchange User Monitor)
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11461
For the travelling consultants and mobile workers out there who like to read technical documentation on airplanes, the SP2 offline help file can be obtained from the download centre.
The TechNet documentation has numerous items that need to be considered to ensure a successful deployment which include:
Over and above this there are some specific issues that I wanted to call out.
Note that you will have to ensure that the prerequisites are installed if you run the GUI installer for the service pack to update an existing Exchange 2010 SP1 server. To achieve this on a Windows 2008 R2 server, open an elevated PowerShell prompt and run:
Import-Module servermanager
Add-WindowsFeature Web-WMI
Alternatively you may run the command line installer, which will install the required OS components:
Setup.com /M:upgrade /InstallWindowsComponents
Of course the above is not a surprise as you did read the release notes?
Note that the method to control Mailbox Replication Service Proxy has changed in SP2. Previously this was enabled/disabled by editing the web.config files for the web application on each individual CAS server. This would typically involve:
When upgrading to SP2 the MRS proxy will be set to a disabled state. Until re-enabled cross-forest mailbox moves will not be processed. This is similar to the behaviour of a defined static TCP port for the Address Book Service when updating from Exchange 2010 RTM to SP1. With Exchange 2010 SP1, you no longer use the “Microsoft.exchange.addressbook.service.exe.config” file to assign a static Exchange Address Book Service RPC port; this configuration is controlled using the registry. Previous custom settings are not preserved. The same is true for MRS proxy and you will need to re-enable it if required.
The great part of the change is that MRS proxy is now controlled by PowerShell in Exchange 2010 SP2, and thus is a great deal easier to manage. MRS proxy is controlled via the Set-WebServicesVirtualDirectory cmdlet and an example of enabling MRSProxy and modifies the maximum number of simultaneous connections that an MRSProxy instance accepts to 50. The default is 100 connections:
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true -MRSMaxConnections 50
Whilst in a transitional stage and all servers are not upgraded to Exchange 2010 SP2 you may receive some warnings relating to your management role definitions. An example would be:
WARNING: The object MyMailboxDelegation has been corrupted, and it's in an inconsistent state. The following validation errors happened: WARNING: The property value you specified, "15", isn't defined in the Enum type "ScopeType".
Note that this issue is not specific to Exchange 2010 SP2, and you may also see it with SP1 RU6 installed. The aspects of this have been discussed on the Exchange team blog and there is also a Knowledgebase article on the topic as well.
When Exchange 2010 is installed it will automatically set the PowerShell execution policy to be RemoteSigned. This is required to allow Exchange setup to run the necessary scripts to install and manage the product. Do not set the Execution policy to restricted, else installations will not complete successfully.
This has been documented previously.
Please note that SP2 requires changes to be made to the Active Directory schema. This information was announced during the development cycle so that everyone would be proactively informed of the pending changes. Details of the schema changes are contained in the documentation. For many customers this will mean that change requests will have to be reviewed, approved and potentially implemented by different teams within the organization. Be sure to account for this when planning for a successful implementation in your environment.
What else can you do to assist with a smooth installation? Leverage the in-box Microsoft provided scripts to start/stop maintenance on DAG members and then re-balance the DAG after maintenance has been completed.
If you take the time and thoroughly prepare for the installation, Exchange 2010 will continue to provide solid messaging services to you organisation.
After installing Internet Explorer 9 onto an Exchange server, you may have experienced that the Exchange Management Console (EMC) will not close. The following error is observed:
You must close all dialog boxes before you can close Exchange Management Console
This did not affect everyone, and you may have been blissfully unaware of this
The Exchange Team Blog originally discussed the issue, and then posted details of a fix.
For even more good news, now you do not need to call into support to get the update, and the following cumulative update for IE should be installed to remediate the issue:
MS11-099: Cumulative Security Update for Internet Explorer: December 13, 2011
In part one of this series we looked at some of the basic aspects of the PowerShell environment. Let’s now look at the underlying mechanics on Exchange 2007 and 2010 servers. We will need to address some aspects separately due to the different mechanisms that are used between Exchange 2007 and Exchange 2010.
For part one please click here.
For part three please click here.
Let’s kick off by looking at the older and simpler of the two, Exchange 2007.
In Exchange 2007 when you open the PowerShell window, the PowerShell snap-ins are loaded up directly into the PowerShell console. This can be easily seen in the PowerShell window by running Get-PSSnapin. Note the differences in the following screenshots where you can see that there are no Exchange specific snap-ins loaded in the first window, whereas these are visible in the second window.
The Exchange 2007 EMS (Exchange Management Shell) where the Exchange SnapIn is visible as:
Name: Microsoft.Exchange.Management.PowerShell.Admin PSVersion: 1.0 Description: Admin Tasks for the Exchange Server
Exchange 2010 EMS showing no Exchange specific snapins loaded.
In Exchange 2007, the EMS creates a local session in which the Exchange cmdlets and non-Exchange cmdlets execute. Note that all Exchange 2007 cmdlets run in this local session even though the command being executed may impact a remote object.
Since Exchange 2007 does not have RBAC (Role Based Access Control – the permission model used in Exchange 2010 and Lync), administrators require access to the machine to start the EMS and also ACLs on the relevant objects (users, mailbox enabled users etc.) that they will manage. It is a challenge to craft the correct ACL so that an administrator, especially a delegated or junior administrator, has the correct level of permissions and to then maintain the correct structure over time due to changes in the environment (e.g. moving users or restructuring Active Directory).
Having to maintain a series of complicated ACLs for Exchange 2003/2007 on a multitude of objects has sometimes been lovingly called “ACL Spray”! Thankfully this is addressed in Exchange 2010 with RBAC, and you can read more about RBAC on this blog.
Exchange 2010 utilises a different mechanism to provide EMS access as it no longer uses a local PowerShell session and instead leverages a remote PowerShell session. This is possible since PowerShell 2.0 introduced a remoting feature. It is critical to understand that this remoting feature is the core of the Exchange 2010 administrative framework. The Windows Remote Management 2.0 (WinRM) service and the Web Services for Management (WS-Management) are the key ingredients that make remoting possible. Regular Windows administrators will typically leverage a fan-out remoting paradigm where their admin machine will reach out and touch multiple other machines. For Exchange 2010 the pattern is reversed as multiple admins will be connecting into a single Exchange server, which is the fan-in model. Since Exchange 2010 leverages remoting this is the reason why the system requirements state that WinRM and PowerShell 2.0 must be installed on both the server and any management workstations.
Note that the Edge server does not leverage remoting.
While WS-Management can be hosted in either IIS or directly in the WinRM service, Exchange 2010 provides its fan-in capabilities by hosting it in IIS. Using the ISAPI paradigm, a single process on the IIS host is used, rather than in the CGI model which would result in multiple processes. If you were to open the IIS manager on an Exchange 2010 server you would see the \PowerShell Virtual Directory (vdir).
With it’s associated application pool:
Note the MSExchangePowerShellAppPool running in the security context of local system which is a requirement for RBAC to function.
The PowerShell IIS vdir works with WinRM to provide the listener for WS-Management requests, and then processes the request.
In order to understand how we connect to a remote session we need to be clear exactly what exists on the local machine and Exchange server respectively. When the standard PowerShell console is opened on a machine, you are interacting in the local computer’s PowerShell runspace; this is the client-side session. This session contains only default PowerShell 2.0 cmdlets because no Exchange 2010 snap-in or module is loaded.
The Exchange 2010 cmdlets will become available after a remote session has successfully been established. This requires that a remote connection is made to an Exchange 2010 server via PowerShell 2.0 which successfully authenticates and then imports the server-side runspace.
Connecting to an Exchange 2010 server creates a remote PowerShell session that is called a PSSession. An established PSSession to an Exchange 2010 server can be seen here:
Note that the –AutoSize has been added to facilitate easier reading.
Since Exchange 2010 cmdlets are available via a remote session, these are not present in the local session, which is why the CommandType in PowerShell is shown as a function rather than as a cmdlet. The difference can be noted in the following screenshots.
Exchange 2007:
Exchange 2010:
Administrators must authenticate to the the WinRM instance that is hosted within IIS on the Exchange server. This can happen implicitly by using the logged on credentials to the domain, or explicitly by providing specific credentials. Note that this is a key step as only the cmdlets, and the specific cmdlet parameters, that a person has been granted access to will be displayed, i.e. RBAC will scope the results. In other words, if you do not have permission to use a cmdlet or a parameter then you will not even see it as an option. This is contained in a server-side runspace, which is then returned to the client-side session when it is represented as a PSSession object in memory. But before the cmdlets in the runspace can be used they must be imported via the PSSession. Once imported, the cmdlets can be used just like any other cmdlet. Importing the PSSession creates a PowerShell module that defines all the cmdlets that are available in the server-side runspace. The module is then loaded up into the local runspace and is shown in the below screenshots.
The Exchange 2010 imported Module piped to Format-List.
This module does not directly contain the actual cmdlets from the server-side runspace, rather the module contains functions that act as references to the server-side cmdlets. When one of these functions is executed, it passes the information needed to execute the cmdlet on the server, and the results are returned to the client-side session. This means that the Exchange 2010 cmdlets run implicitly in the session from which they were imported from. Administrators do not need to worry about this as PowerShell manages such aspects in the background.
Now that we have looked at some of the plumbing that is used, what mechanisms does an administrator have to start the EMS? There are two ways that they can connect to an Exchange 2010 server using PowerShell:
Both of these have their own pros and cons, so let’s take a look at them.
Typically Exchange administrators will use the EMS shortcut created automagically by Exchange setup. This shortcut will automatically connect to the nearest Exchange 2010 server. Note that this requires the workstation/server to be domain joined to the forest where Exchange 2010 is installed.
In the Exchange server \Bin directory the following scripts are used with the EMS shortcut.
The New-PSSession is used by the ConnectFunctions.ps1 script in an attempt to connect to the determined server. The function displays a message identifying the server identified. If the connection succeeds and the new PSSession object is created, the function proceeds to import the runspace. If the automatic connection attempt were to fail, an error is displayed, and the function moves on to the next server in the list. Should all automatic connection attempts fail, the administrator is prompted to enter a server to connect to.
When a connection is successfully completed, the Connect-ExchangeServer function creates a PSSession object and stores it in memory. Once saved the implicit client-side session is created. The PSSession object will contain all the cmdlets, functions, aliases that RBAC will make available to the specified user, though they will not be available until they are imported from the PSSession and loaded up into the local PowerShell session using the implicit remoting module. Connect-ExchangeServer uses Export-PSSession cmdlet to generate an implicit remoting module which is then imported using the import-module
The above let us easily use the EMS in an simple manner so we get the familiar screen as shown here:
Though the general recommendation is that Administrators use the provided shortcut that is created when the Exchange Management Tools are installed, it is also possible to start the EMS manually. Manual connections still requires the same prerequisites as the EMS shortcut (i.e. WinRM 2.0 and PowerShell 2.0).
Since the connection is being made manually the RemoteExchange.ps1 script is not used so the functions, aliases and variables loaded by the script are not available. Because of these factors and the extra administrator overhead, the management experience is not as complete as the the automatic connection provided by the EMS shortcut.
Since this is harder why would we want to do this? We can connect to Exchange 2010 from a machine that is not joined to the same forest so it lights up remote management options. We also do not have to have the Exchange 2010 management tools installed on the local machine. Since Exchange 2010 is only available in x64, this allows x86 workstations to be used to administrator Exchange 2010.
Note that some additional aspects must be considered to allow connections from workstations that are not joined to the same forest. Domain joined machines can use integrated windows authentication, but this is not possible for workgroup machines that will have to explicitly provide credentials. The authentication must be enabled on the PowerShell vdir which is not configured by default.
Exchange 2010 EMS only allows secured and encrypted connections by default. For machines in the same forest, Kerberos authentication is used and EMS connects to port 80 TCP on the Exchange server. For untrusted domains or workgroup machines, HTTPS must be used for encryption which means that the remote machine trusts the certificate used on Exchange or the PSSession option to ignore certificate errors is set.
Here is a manual connection from a Windows 7 machine in the same forest as Exchange that does not have the Exchange 2010 Management Tools installed.
Firstly let us enter the credentials to the administrator account since we are logged on as a domain user account:
$Credentials = Get-Credential
Now that the credentials are saved, we can create a new session with those credentials:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2010 server>/PowerShell/ -Authentication Kerberos -Credential $Credentials
Finally, we can import the session:
Import-PSSession $Session
Once the module has been imported, we have the capability to run all the Exchange tasks that we are permitted by RBAC.
Again note the title bar – this is the x86 PowerShell window that is used.
When the task has been completed the PSSession can be removed:
Remove-PSSession $Session
Note that Get-Mailbox no longer works since we do not have access to the remote server.
For the security conscious amongst us, you may have noted that the connection URL is HTTP rather than HTTPS in this scenario. This is because the workstation was in the same forest as the Exchange server so we could use Kerberos. Even though we connect to the /PowerShell vdir using HTTP, the connection is encrypted using Kerberos and data is not passed over the wire in clear text.
Ilse has a great write up on this over on her most awesome blog, I encourage you to subscribe to her RSS feed.
This is an example of a machine in a non-trusted forest connecting to Exchange in a separate forest.
Note the errors relating to the certificate. Since the certificate is not trusted we need to set the options in the PSSessionOption to skip the certificate checks.
Now that the certificate issue has been ignored, we can see the next issue, as the PowerShell vdir is not set to allow authentication by default.
Windows Integrated was then enabled on the vdir since it was not previously enabled. Note that Windows Authentication is now set to Enabled.
After enabling authentication we are able to connect and run cmdlets.
Hope you found this helpful. Let me know if you have any questions or comments.
Was discussing cross forest mailbox move operations with a customer last week to review the details around network requirements for remote move requests. This is as opposed to a local move request which is used within the same Exchange Organisation.
Relevant TechNet documentation:
Create a Remote Move Request That has Exchange 2010 in Both Forests
Create a Remote Legacy Move Request Where One of the Forests Doesn't Have Exchange 2010
Prepare Mailboxes for Cross-Forest Move Requests
Prepare Mailboxes for Cross-Forest Moves Using the Prepare-MoveRequest.ps1 script in the Shell
Prepare Mailboxes for Cross-Forest Moves Using Sample Code
Start the MRSProxy Service on a Remote Client Access Server
Note that the method to enable MRS proxy has changed in Exchange 2010 SP2 as mentioned in my previous post and in the above TechNet documentation.
In addition to the above, Nagesh Mahadev also posted a great write up onto the Exchange Team Blog. My favourite section being the network requirements which has a table of the ports required for move request to function:
Port
Protocol
808 (TCP)
Mailbox Replication Service uses to communicate
53 (TCP)
DNS
135 (TCP)
RPC End Point
389 (TCP)
LDAP
3268 (TCP)
1024 > (TCP)
if mailbox store is not statically configured then 1024 higher ports need to be open
88 (TCP)
Kerberos
445 (TCP)
Microsoft-DS Service (File sharing)
443 (TCP)
Mailbox Replication Proxy service uses port 443 to communicate with other Exchange 2010 client access server via HTTPS.
Note that name resolution is required between the forests.
Update: Newer firmware has been released since this was originally posted.
Ran into an interesting issue last week with a HP DL 585 Hyper-V host which had intermittent network connectivity over one of its defined virtual networks.
In the system event log the following warning was logged:
To resolve the issue, HP has released an updated NIC driver which is dated 11-11-2011.
The below is pasted from above to facilitate easier searching:
DEVICE: HP NC375T PCI Express Quad Port Gigabit Server Adapter
PROBLEM: Tx path is hung. The device is being reset.
ACTION: Adapter recovers from this error automatically.
Version: 4.4.8.812 (11 Nov 2011)
Fixes
Upgrade Requirement: Optional - Users should update to this version if their system is affected by one of the documented fixes or if there is a desire to utilize any of the enhanced functionality provided by this version.
This driver corrects an issue which could result in the adapter losing connectivity and writing “TX path hung. Device being reset” to the system event log.
This driver no longer provides the ability to configure the adapter for half-duplex operation
The driver update is downloadable from here.