A lot of companies are used to waiting for a disaster to happen in order to react. Only until there’s a service outage within their IT department do they take action instead of being more proactive and in control of their IT. The problem is that they don’t know where or how to get started in having a proactive approach to monitoring, even more so when they have a lot of infrastructure that needs to be monitored.
As a first step, IT needs to understand the business: all good designs come from understanding your IT services data dependencies and knowing how they relate to one another. Then they need to find out what are the best tools available today.
Microsoft System Center Operations Manager (SCOM) is a great platform to monitor components, and which a lot of people in the industry are already familiar with. There’s a lot of useful information within SCOM that can be used by the different personas in the company, however, the presentation layer and the way it is organized within SCOM is not the way those other personas look at IT. SCOM is still pretty technical and is all about components.
Looking at the personas in the IT service delivery organization, you will see that engineers definitely can work with SCOM. However, it usually takes them a while to figure out how they can easily get to the root-cause of a service outage, and what the business impact is of this outage will be.
Savision’s new whitepaper: “Business Service Management with System Center”, shows how to stay in control of your business services and make the most out of SCOM. Click here to download the whitepaper. The whitepaper is written by three experts: Microsoft MVP Robert Hedblom, Savision’s Co-Founder & VP of Product Management Dennis Rietvink, and Approved Consulting’s CEO & Solution Architect Jonas Lenntun.
It’s not like everyday you might want to remove certain management packs from your SCOM management group. The most painful task is removing the dependent MPs as you need to manually track all of those and delete them first in order to successfully remove the parent management pack.
Microsoft Senior Software Engineer Chandra Bose has written a PowerShell script that can identify and remove all of the dependent management packs automatically in such situations. Lets explore that script a little in this post.
How to get started?
First of all you need to run the Operations Manager Command shell as an administrator, which should be a member of the Operations Manager Administrators group as well.
When you execute the script you can either provide the ID or the System Name of the parent management pack as below. You can find the MP ID by visiting Administration > Management Packs > Right click the desired MP and select properties > Look for the ID field in the General tab which shows the MP ID. The System Name is the unique name of the MP (i.e Microsoft.SQLServer.2012.Discovery)
.\RecursiveRemove.ps1 <ID or System Name of the MP>
You can download the RecursiveRemove.ps1 script from here.
Last week I was deploying a new Azure Stack POC deployment with my friend CDM MVP Nirmal Thewarathanthri. While we were working on the SQL RP deployment there was a strange issue. The problem was every time when the SqlRPTemplateDeployment.ps1 was executed, it always failed with below error.
New-AzureRmResourceGroupDeployment : InvalidApiVersionParameter: The api-version ‘2015-11-01’ is invalid. The supported versions
At D:\SQLRP\AzureStack.SqlRP.Deployment.184.108.40.206\Content\Deployment\SqlRPTemplateDeployment.ps1:207 char:5
+ New-AzureRmResourceGroupDeployment -Name “newSqlRPTemplateDeploym …
Wrong Azure PowereShell version
The Azure Stack documentation instructs us to update to the latest version of AzurePowerShell in the Client VM before deploying the SQL RP. But the latest version 1.2.2 released in March seems not supported in this scenario. When we downgraded that to version 1.2.1 (February version) we were able to continue with the SQL RP deployment.
If you are using the web installer for Azure PowerShell be mindful to avoid that at least for now. You can explore all the releases from GitHub and download them as MSI packages.
“Save Our Souls” is the International distress call for help in maritime operations. Over the years SOS has become more common term to imply a call for help in a disastrous situation. In Microsoft Azure sometime you may have faced such situations especially with IaaS VMs. For an example RDP not working in a Windows VM or SSH ceased to function in a Linux VM. When all hope is lost you may contact Azure Support or try to restart the VM (from Azure Portal) or resize the VM as a last resort.
Now going into all of the above troubles is no longer required to rescue your Azure IaaS VMs. The latest Microsoft Azure PowerShell cmdlet improvements allows you to redeploy your virtual machine when you invoke a redeploy operation through Azure PowerShell.
- Below cmdlet works only with Azure Resource Manager based VMs.
- Latest version of Azure PowerShell needs to be installed in the management PC from which you are invoking the redeploy operation.
- Dynamic IP addresses will be changed after completing the redeploy operation.
- Data on local disks (ephemeral storage) will be lost.
Following is the syntax for the updated Set-AzureRmVM cmdlet. Note that the -Redeploy switch is used to invoke a redeploy operation.
Set–AzureRmVM –Redeploy –ResourceGroupName $rgname –Name $vmname
The VM status changes from Running > Updating > Starting > Running during the operation. The final Running status means that VM has been successfully redeployed.
For a complete reference of the Set-AzureRmVM cmdlet please refer here.
Microsoft has released the Update rollup 9 for Data Protection Manager 2012 R2 a little over one month back. This UR contains a number of significant improvements to the current DPM version thereby enabling more capabilities for your enterprise backup strategy.
Here are four reasons that you should consider to apply this UR.
No need for consistency check for file server backups in case of a DPM Filter corruption
When your production file servers encounter an unexpected downtime, DPM file tracking filter gets corrupted and results in an inconsistent replica. In UR9 DPM leverages USN journal to track the changes in files, thereby running a consistent check to repair the damaged filters is no longer needed. The repair operation will be displayed as a synchronization job in DPM which will also sync the replica to latest. Running a consistency check is really painful especially when the replica is huge.
Say Goodbye to Production Server Restart
One of the biggest headaches while upgrading the DPM agent is the requirement to restart the protected servers unlike SCOM or SCCM agents. Finally Microsoft has got rid of the restart requirement. Microsoft has eliminated all the causes for restarting servers while upgrading DPM agents except the filter driver update. Any backup products that perform incremental backups use a filter driver, and whenever there is an update to the filter driver a reboot is needed. If you are already on UR6 or above you can easily upgrade your DPM agents without the restart requirement. So unless any future UR doesn’t contain a filter driver update no restart required at all.
Cache Space for Online Backup has been reduced
In previous versions of Microsoft Azure Backup Agent local disk cache space requirement was 15% of the data source size for backup to Azure which is a big issue if your data source is over 10 TB. This has been reduced to 5% now.
Number of Recovery Points for Online Backups has been increased
For organizations with strict industry compliance requirements the need to have longer retention policies is a mandatory requirement. DPM now supports 9999 recovery points for a online backup in Azure where previously it was 366. This enables more flexible and consistent recovery policies for cloud backup.
You can refer the full KB article and download the binaries for UR9 package from here.