Installing SP2 is a relatively straightforward affair and Exchange 2010 SP1 and SP2 servers can co-exist peacefully alongside each other for as long as it takes to roll out SP2. However, it is best practice to run a consistent software level across an entire Exchange organization so it’s best to schedule the updates to occur as quickly as possible. Of course, don’t do this until after you’re happy that SP2 meets your needs and requirements and has been tested in your own environment.
The biggest hindrance in the update process for most people is likely to be the requirement to schedule the prerequisite Active Directory schema update, which is required to support new features such as Address Book Policies (ABPs). Once the schema has been updated and replicated throughout the Active Directory forest, you should be able to upgrade Exchange 2010 SP1 servers following the normal order of CAS-Hub Transport-Mailbox servers (Edge servers can be updated first or last, UM servers should be updated before mailbox servers). CAS servers in Internet-facing sites are usually the first candidates for upgrade and this is especially so in Exchange 2010 SP2 if you plan to run a hybrid on-premises/Office 365 configuration. Those who run multi-role Exchange 2010 servers can simply start to upgrade servers…
Updates are performed from the command line with the SETUP program or by running the normal Exchange 2010 installation program. If you run SETUP, you’ll probably run the command SETUP /m:upgrade /InstallWindowsComponents to apply the upgrade and to install any Windows components that might be missing on a server.
If you use the GUI version of the installation program to install SP2, you might encounter the error shown above when you attempt to upgrade Exchange 2010 SP1 CAS servers. This is because SP2 introduces a new requirement for CAS servers to have the IIS6 WMI Compatibility role. The Exchange installation program is able to detect the lack of prerequisite software on a server and offer to install the missing pieces for you but it can only do this for new installations as the code doesn’t cover the situation where a service pack or other upgrade introduces the need for a new component. As you’ll already have noted from the command-line example described above, the same limitation doesn’t exist for SETUP.
For those who like to script server updates, you can use PowerShell to run these commands to ensure that the correct prerequisite software is installed for Exchange 2010 SP2 (the change from previous versions is the addition of the Web-WMI component):
Import-Module ServerManager
Add-WindowsFeature NET-Framework, RSAT-ADDS, Web-Server, Web-Basic-Auth, Web-Windows-Auth, Web-Metabase, Web-Net-Ext, Web-Lgcy-Mgmt-Console, WAS-Process-Model, RSAT-Web-Server, Web-ISAPI-Ext, Web-Digest-Auth, Web-Dyn-Compression, NET-HTTP-Activation, RPC-Over-HTTP-Proxy, Web-WMI –Restart
For mailbox servers that are members of a Database Availability Group, remember that Exchange includes a script called StartDagServerMaintenance.ps1 that is designed to prepare a DAG server member for maintenance, such as installing a service pack. This script:
Runs the Suspend-MailboxDatabaseCopy cmdlet for each database copy hosted on the DAG member to block replication and replay activity.
Pauses the node in the cluster. This prevents the server taking on the role of the Primary Active Manager (PAM) for the DAG
Sets the value of the DatabaseCopyAutoActivationPolicy parameter on the DAG member to “Blocked“. This step prevents the PAM attempting to automatically activate any of the database copies that are present on the server.
Moves all the active databases that are currently hosted on the DAG member to other DAG members. Assuming that there are DAG members available to accept the workload, clients should be automatically transferred to the new locations by the RPC Client Access Layer.
Like all the other scripts included in the Exchange kit, you can find this one in the location \Program Files\Microsoft\Exchange Server\V14\Scripts. You’ll also find its companion script that’s designed to bring a DAG member back online after maintenance is complete, StopDagServerMaintenance.ps1, in the same location. This script does the following:
Runs the Resume-MailboxDatabaseCopy cmdlet for each database copy hosted on the DAG member to allow the server to fully participate in database replication and replay.
Resumes the node in the cluster to enable full cluster functionality for the DAG member
Sets the value of the DatabaseCopyAutoActivationPolicy parameter on the DAG member to be “Unrestricted“. The PAM is then able to automatically activate database copies on the DAG member.
Note that workload is not automatically transferred back to the newly reenabled DAG member. You will have to either perform a manual switchover of databases to make them active on the DAG member or rely on the update of another DAG member to transfer databases and balance workload across the DAG. Inevitably, you will end up switching some databases around once all the servers have been upgraded to SP2.
As an example, here’s how we would run the scripts to work with a server called ExServer1 during maintenance.
1. Navigate to the scripts directory (or do one of the tricks to get the scripts directory in your search order for PowerShell).
2. Run the script to prepare a DAG server member for maintenance.
.\StartDagServerMaintenance -ServerName "EXSERVER1"
3. When maintenance is done, run the other script to bring the server back online within the DAG.
.\StopDagServerMaintenance -ServerName "EXSERVER1"
All in all, your upgrade to SP2 should proceed reasonably smoothly and with a minimum of fuss. Microsoft has invested lots of time into making it all flow nicely and you’ll appreciate their work after the upgrade is complete.
algunos link:
http://blogs.technet.com/b/exchange/archive/2011/12/05/released-exchange-server-2010-sp2.aspx
download
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28190
prerequisitos
http://technet.microsoft.com/en-us/library/bb691354.aspx
en resumen tener en cuenta el tema de los CAS y en los Mailbox server el script StartDagServerMaintenance.ps1
suerte.
The biggest hindrance in the update process for most people is likely to be the requirement to schedule the prerequisite Active Directory schema update, which is required to support new features such as Address Book Policies (ABPs). Once the schema has been updated and replicated throughout the Active Directory forest, you should be able to upgrade Exchange 2010 SP1 servers following the normal order of CAS-Hub Transport-Mailbox servers (Edge servers can be updated first or last, UM servers should be updated before mailbox servers). CAS servers in Internet-facing sites are usually the first candidates for upgrade and this is especially so in Exchange 2010 SP2 if you plan to run a hybrid on-premises/Office 365 configuration. Those who run multi-role Exchange 2010 servers can simply start to upgrade servers…
Updates are performed from the command line with the SETUP program or by running the normal Exchange 2010 installation program. If you run SETUP, you’ll probably run the command SETUP /m:upgrade /InstallWindowsComponents to apply the upgrade and to install any Windows components that might be missing on a server.
If you use the GUI version of the installation program to install SP2, you might encounter the error shown above when you attempt to upgrade Exchange 2010 SP1 CAS servers. This is because SP2 introduces a new requirement for CAS servers to have the IIS6 WMI Compatibility role. The Exchange installation program is able to detect the lack of prerequisite software on a server and offer to install the missing pieces for you but it can only do this for new installations as the code doesn’t cover the situation where a service pack or other upgrade introduces the need for a new component. As you’ll already have noted from the command-line example described above, the same limitation doesn’t exist for SETUP.
For those who like to script server updates, you can use PowerShell to run these commands to ensure that the correct prerequisite software is installed for Exchange 2010 SP2 (the change from previous versions is the addition of the Web-WMI component):
Import-Module ServerManager
Add-WindowsFeature NET-Framework, RSAT-ADDS, Web-Server, Web-Basic-Auth, Web-Windows-Auth, Web-Metabase, Web-Net-Ext, Web-Lgcy-Mgmt-Console, WAS-Process-Model, RSAT-Web-Server, Web-ISAPI-Ext, Web-Digest-Auth, Web-Dyn-Compression, NET-HTTP-Activation, RPC-Over-HTTP-Proxy, Web-WMI –Restart
For mailbox servers that are members of a Database Availability Group, remember that Exchange includes a script called StartDagServerMaintenance.ps1 that is designed to prepare a DAG server member for maintenance, such as installing a service pack. This script:
Runs the Suspend-MailboxDatabaseCopy cmdlet for each database copy hosted on the DAG member to block replication and replay activity.
Pauses the node in the cluster. This prevents the server taking on the role of the Primary Active Manager (PAM) for the DAG
Sets the value of the DatabaseCopyAutoActivationPolicy parameter on the DAG member to “Blocked“. This step prevents the PAM attempting to automatically activate any of the database copies that are present on the server.
Moves all the active databases that are currently hosted on the DAG member to other DAG members. Assuming that there are DAG members available to accept the workload, clients should be automatically transferred to the new locations by the RPC Client Access Layer.
Like all the other scripts included in the Exchange kit, you can find this one in the location \Program Files\Microsoft\Exchange Server\V14\Scripts. You’ll also find its companion script that’s designed to bring a DAG member back online after maintenance is complete, StopDagServerMaintenance.ps1, in the same location. This script does the following:
Runs the Resume-MailboxDatabaseCopy cmdlet for each database copy hosted on the DAG member to allow the server to fully participate in database replication and replay.
Resumes the node in the cluster to enable full cluster functionality for the DAG member
Sets the value of the DatabaseCopyAutoActivationPolicy parameter on the DAG member to be “Unrestricted“. The PAM is then able to automatically activate database copies on the DAG member.
Note that workload is not automatically transferred back to the newly reenabled DAG member. You will have to either perform a manual switchover of databases to make them active on the DAG member or rely on the update of another DAG member to transfer databases and balance workload across the DAG. Inevitably, you will end up switching some databases around once all the servers have been upgraded to SP2.
As an example, here’s how we would run the scripts to work with a server called ExServer1 during maintenance.
1. Navigate to the scripts directory (or do one of the tricks to get the scripts directory in your search order for PowerShell).
2. Run the script to prepare a DAG server member for maintenance.
.\StartDagServerMaintenance -ServerName "EXSERVER1"
3. When maintenance is done, run the other script to bring the server back online within the DAG.
.\StopDagServerMaintenance -ServerName "EXSERVER1"
All in all, your upgrade to SP2 should proceed reasonably smoothly and with a minimum of fuss. Microsoft has invested lots of time into making it all flow nicely and you’ll appreciate their work after the upgrade is complete.
algunos link:
http://blogs.technet.com/b/exchange/archive/2011/12/05/released-exchange-server-2010-sp2.aspx
download
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28190
prerequisitos
http://technet.microsoft.com/en-us/library/bb691354.aspx
en resumen tener en cuenta el tema de los CAS y en los Mailbox server el script StartDagServerMaintenance.ps1
suerte.
Comentarios