Tag Archives: execute

Curb stress from Exchange Server updates with these pointers

systems. In my experience as a consultant, I find that few organizations have a reliable method to execute Exchange Server updates.

This tip outlines the proper procedures for patching Exchange that can prevent some of the upheaval associated with a disruption on the messaging platform.

How often should I patch Exchange?

In a perfect world, administrators would apply patches as soon as Microsoft releases them. This doesn’t happen for a number of reasons.

Microsoft has released patches and updates for both Exchange and Windows Server that cause trouble on those systems. Many IT departments have long memories, and they will let the bad feelings keep them from staying current with Exchange Server updates. This is detrimental to the health of Exchange and should be avoided. With proper planning, updates can and should be run on Exchange Server on a regular schedule.

Another wrinkle in the update process is Microsoft releases Cumulative Updates (CUs) for Exchange Server on a quarterly schedule. CUs are updates that feature functionality enhancements for the application.

With proper planning, updates can and should be run on Exchange Server on a regular schedule.

Microsoft plans to release one CU for Exchange 2013 and 2016 each quarter, but they do not provide a set release date. The CUs may be released on the first day of one quarter, and then on the last day of the next.

Rollup Updates (RUs) for Exchange 2010 are also released quarterly. An RU is a package that contains multiple security fixes, while a CU is a complete server build.

For Exchange 2013 and 2016, Microsoft supports the current and previous CU. When admins call Microsoft for a support case, the company will ask them to update Exchange Server to at least the N-1 CU — where N is the latest CU, N-1 refers to the previous CU — before they begin work on the issue. An organization that prefers to stay on older CUs limits its support options.

Because CUs are the full build of Exchange 2013/2016, administrators can deploy a new Exchange Server from the most recent CU. For existing Exchange Servers, using a new CU for that version to update it should work without issue.

Microsoft only tests a new CU deployment with the last two CUs, but I have never had an issue with an upgrade with multiple missed CUs. The only problems I have seen when a large number of CUs were skipped had to do with the prerequisites for Exchange, not Exchange itself.

Microsoft releases Windows Server patches on the second Tuesday of every month. As many administrators know, some of these updates can affect how Exchange operates. There is no set schedule for other updates, such as .NET. I recommend a quarterly update schedule for Exchange.

How can I curb issues from Exchange Server updates?

As every IT department is different, so is every Exchange deployment. There is no single update process that works for every organization, but these guidelines can reduce problems with Exchange Server patching. Even if the company has an established patching process, if it’s missing some of the advice outlined below, then it might be a good idea to review that method.

  • Back up Exchange servers before applying patches. This might be common sense for most administrators, but I have found it is often overlooked. If a patch causes a critical failure, a recent backup is the key to the recovery effort. Some might argue that there are Exchange configurations — such as Exchange Preferred Architecture — that do not require this, but a backup provides some reassurance if a patch breaks the system.
  • Measure the performance baseline before an update. How would you know if the CPU cycles on the Exchange Server are too high after an update if this metric hasn’t been tracked? The Managed Availability feature records performance data by default on Exchange 2013 and 2016 servers, but Exchange administrators should review server performance regularly to establish an understanding of normal server behavior.
  • Test patches in a lab that resembles production. When a new Exchange CU arrives, it has been through extensive testing. Microsoft deploys updates to Office 365 long before they are publicly available. After that, Microsoft gives the CUs to its MVP community and select organizations in its testing programs. This vetting process helps catch the vast majority of bugs before CUs go to the public, but some will slip through. To be safe, test patches in a lab that closely mirrors the production environment, with the same servers, firmware and network configuration.
  • Put Exchange Server into maintenance mode before patching: If the Exchange deployment consists of redundant servers, then put them in maintenance mode before the update process. Maintenance mode is a feature of Managed Availability that turns off monitoring on those servers during the patching window. There are a number of PowerShell scripts in the TechNet Gallery that help put servers into maintenance mode, which helps administrators streamline the application of Exchange Server updates.

Use the Azure Custom Script Extension for your Azure VMs

It’s easy to execute custom scripts — including PowerShell scripts — in a VM running in on-premises Hyper-V hosts….

“;
}
});

/**
* remove unnecessary class from ul
*/
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

/**
* Replace “errorMessageInput” class with “sign-up-error-msg” class
*/
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {
$(this).removeClass(“errorMessageInput”).addClass(“sign-up-error-msg”);
}
});
}

/**
* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
*/
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
renameErrorMsgClass();
return validateReturn;
}

/**
* DoC pop-up window js – included in moScripts.js which is not included in responsive page
*/
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {
window.open(this.href, “Consent”, “width=500,height=600,scrollbars=1”);
e.preventDefault();
});

All you need to do is create a script that the destination VM can support and then run it via PowerShell Direct or copy the script to the VM. Azure also supports executing custom scripts in Azure VMs, but the way you execute them is slightly different.

Azure Custom Script Extension is a plug-in designed to only work with Azure VMs. It can be used to execute scripts stored in an Azure blob container or in a valid URL that’s accessible by Azure Portal and PowerShell command lines. Before you execute scripts inside Azure VMs, you’ll be required to decide the source of the script and resource group name in which the Azure VM is located. If your script is stored in an Azure blob container, you’ll be required to supply the storage account name, storage account key and blob container where the script is located. By executing the command below, you’re executing a script stored in an Azure blob container named VMScripts:

Set-AzureRMVMCustomScriptExtension –ResourceGroupName “RSGroup1” –Location “Central US” –VMName “SQLVM” -StorageAccountName “StorageAccount1” –StorageAccountKey {StorageAccountKeyHere} –FileName “ThisScript.PS1” –ContainerName “VMScripts”

If you have a script available in other locations, such as GitHub, you’ll be required to download the script from GitHub to the Azure VM as it’s shown in the command below:

Set-AzureRMVMCustomScriptExtension –ResourceGroupName “RSGroup1” –VMName “SQLVM” –Name “VMScripts” –FileURI {Complete Script Path here} –Run “ScriptFile.PS1” –Location “Central US”

Azure Custom Script Extension is available for both Azure Windows and Linux VMs. You can execute any PowerShell script in Azure Windows VMs and any Bash scripts in Azure Linux VMs.

Troubleshooting issues

If you face any issues during execution of the scripts, you might want to check execution logs found under C:WindowsAzureLogsPlugins
Microsoft.Compute.CustomScriptExtension in Azure VMs. If the script failed to execute, make sure the script was downloaded to Azure VMs from either a storage blob container or URL. Scripts are downloaded to the C:
PackagesPluginsMicrosoft.Compute.CustomScriptExtension1.*Downloads location in the Azure VM.

You might want to execute custom scripts using Azure Custom Script Extension to support post-deployment configurations, such as configuring OS settings and installing line-of-business applications.

Next Steps

Learn more about Azure Security Center

Solve API problems in Azure

Avoid downtime with Azure availability sets

Dig Deeper on Cloud computing architecture

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever’s puzzling you.