Category OMS

I was recently working on an Azure Automation runbook that provisions an empty resource group in Azure. I was running into an issue when the runbook ran that the variable being used with New-AzureRmRoleAssignment was null. The errors I was receiving are:

You may have a some differences like the connection variable and the name of the runasconnection. The point here is that the runas connection is what needs to have the proper permissions. You can find this account here to get the name and ApplicationID:

To give the permissions go to Azure Active Directory>the directory you are using in this automation>App registrations>and search based on the ApplicationID. Don’t forget to select All apps in the drop down.

Click on Add first and add the AAD and then Microsoft Graph permissions.

After you add the proper permissions make sure you click on Grant Permissions. The permissions are not actually applied until you do this. Once you click on Grant permissions you will see the prompt shown in the screenshot. Click Yes.

Verify the permissions have been added properly. In AAD go to All applications>select All applications. Find your service principle application.

Click on the service principle applications permissions.

Verify the AAD and graph permissions are listed. If the AAD and graph permissions are listed then the runbook should be good to go.

For those that know me know that I have been a System Center expert for some time focused on helping organizations manage their IT along with their ITSM needs. I have been working with Azure since it was released off and on but started to get serious about Azure after Microsoft’s move to resource manager. And even more recently I have re-focused completely to Azure and DevOps along with ITSM in the context of the cloud. I consider this combination CloudOps.

CloudOps is important when it comes to cloud and supporting DevOps. A part of CloudOps is cloud management. More specifically the tooling name for cloud management is often referred to as Cloud Management Platform (CMP). CMP’s can be a CloudOps architect and engineers best friend or worst nightmare. There are many CMP solutions out there in the market that can be used to manage Azure and other clouds as well. Microsoft has done a nice job building and bringing in native solutions that can be used to manage Azure. The following image depicts the areas of cloud management that are in focus for Microsoft.

I am sure the plan for native cloud management will change and expand over time as Azure and its management needs continue to grow. The native set of cloud management tools in Azure can be viewed as a CMP. I am going to put together a group of blogs that at a high level cover the native solutions that exist for managing and securing Azure. There are so many areas in this topic that it has to be broken out into a blog series. This is the first time I am doing a blog series. It will cover the following:

Migrating to Azure is a big task and should not be taken lightly. It is important to do your due diligence when embarking on this journey. There have been tools available for a while to assist in migrating to public clouds both for Microsoft Azure and non-Microsoft. Some of the tools out there have been designed and built for Azure migrations and some originally for backup and or disaster recovery but work well helping to migrate workloads. Also with cloud there is IaaS, PaaS, and even SaaS. When looking to migrate from on-premises those are the types that you look at moving to. In this blog post I will talk about migrating to IaaS on Azure and will take a look at the newly announced migration tool from Microsoft. This new migration tool from Microsoft is called Azure Migrate. It was announced here: https://azure.microsoft.com/en-us/blog/announcing-azure-migrate and it is still in a limited preview. The most common type of migration project from on-premises to Azure is known as a Lift and Shift to IaaS. This is the standard approach including the tooling:

Stage 1: Discover and assess on-premises environment and workloads that will be moved to Azure.

Now it is common in stage 1 to assess workloads that can move to SaaS or PaaS. Below is a Workload Cloud Migration Decision Tree that can be used to help determine the placement of workloads as you look at migrating to the Azure:

This decision tree flow is from the Azure Operationalized session MVP Natascia Heil and myself delivered in 2017 at MMS. Notice in the Workload Cloud Migration Decision Tree that SaaS is first then PaaS, then IaaS and finally Hybrid Cloud. That is the order workloads should be targeted in as the top typically has the lowest cost and greatest amount of savings when moving to cloud. Also take note that Hybrid Cloud is Azure Stack.

Reminder in this blog post we are only talking about IaaS as that is what the Azure Migrate tool can help with as of now. This may change later expanding to cover PaaS and I hope it does!

Azure Migrate was announced at Ignite 2017. It is still in a limited preview. I am fortunate to have access to it and was given the green light to blog about it. Azure Migrate can help with stage 1 of an Azure migration project. Azure Migrate helps eliminate a fair amount of the manual work needed in Azure migration projects. Currently Azure Migrate only evaluates environments and workloads running in VMWare vSphere. Later the goal is to add Hyper-V and physical servers as platforms that can also be assessed.

– Azure readiness of on-premises virtual machines. This looks at things such as the type of BIOS, OS version.

– Size recommendations gives you a recommended Azure IaaS VM sized based on the VM’s on-premises performance history.

– Monthly cost estimate is the total cost you will incur running your servers in Azure. This is broken down as compute and storage costs.

– Visualizing dependencies is basically utilizing Service Map to visualize dependencies between servers so you can scope out servers that make up a workload at the application level and quickly determine any potential issues with migrating.

The Azure Migrate tool looks at the following items as a part of the assessment:

Target location

The Azure location to which you want to migrate.

Storage redundancy

The storage option that Azure VMs will use after migration. Currently, Azure Migrate supports only Locally redundant storage (LRS) only.

Pricing plans

The assessment takes into account whether you’re enrolled in Software Assurance and can use the Azure Hybrid Use Benefit, and whether you have any Azure offers that should be applied. It also allows you to specify any subscription type.

Pricing tier

Azure Migrate allows you to specify the pricing tier (basic/standard) of the Azure VMs. This helps you migrate to the right Azure VM family, based on whether your on-premises environment is in production or not.

Performance history

By default, Azure Migrate evaluates on-premises machine performance using a month of history, with a 95% percentile value. This can be modified.

Comfort factor

Azure Migrate considers a buffer (comfort factor) during assessment. This buffer is applied on top of the utilization data of VMs (for CPU, memory, disk and network). The comfort factor is added to account for matters such as seasonal usage, short performance history, and likely increases in future usage. For example, normally a 10-core VM with 20% utilization will result in a 2-core VM.

Note: Above list is from the limited preview user guide and subject to change once Azure Migrate is out of preview.

Overall I found Azure Migrate easy to setup, configure and use. Now let’s check out the tool.

When you go into the Azure portal you basically create a new migration project. This is stored in it’s own resource group. You can create multiple of these.

When you create an Azure migration project it creates an OMS workspace and deploys the Service Map solution. This can be seen in the following screenshot.

After creating the project you then need to perform the discovering and assessment.

To perform the discovery Microsoft gives you a appliance in the form of a VMware virtual machine image. This is the migration collector. You spin it up in your vSphere environment, connect it to your VMWare environment and let it collect data on all or a specified set of virtual servers.

In the following screenshot you can see the collector running.

After it is running you need to log into it via the VMWare console or RDP. You need to ensure the VMware PowerCLI module is installed and then you run the Azure Migrate collector wizard. On the desktop of the collector machine’s desktop you wil see the VMWare PowerCLI for installing it and the collector wizard.

This is a screenshot of the VMWare PowerCLI install.

Below in the following screenshots is what the collector wizard looks like. On the first screen accept the pre-reqs and click continue. On the second section you are going to point the collector at your VMWare environment to collect either or specific VM’s that you plan to migrate to Azure.

Next you need to input credentials for the Azure Migration project that you created in Azure. Below is a screenshot of the ID and Key.

Input the ID and key as shown in the screenshot below.

After you click continue the wizard will discover the machines and upload the date to your Azure Migration project. This can take a while so go get some coffee at this point.

After it is done go back to the Azure portal and go to Migration projects. This is where you will see the Azure migration project you created and the details of your assessment.

Below are two screenshots one without assessments and one with assessments.

Without any assessments

With some assessments

On the left hand side under manage you can click on assessments to create an assessment. You can create a new group or select an existing group for the machines to belong to.

The following screenshot is what the assessment overview will look like.

You can change many important things for your migration by clicking on Edit properties. Here you can change the target location for the VM’s storage type, offer type, use of hybrid user benefit and much more. There is a property here names comfort factor. If the comfort factor is set to of 1 the migrate tool will provide only exactly what is needed if this is set higher for example to a comfort factor of 2 then the migrate tool will double the VM size recommended by Azure migrate.

If you click on Azure readiness it will show you the migration readiness details about your VM’s. Here you will see any machines that will have migrations issues and what those issues are so that you can remediate them. After you remediate this will update.

If you click on a machine it will give you details about that specific VM.

If you click on Cost details you will see a breakdown of monthly compute and storage costs. It will break this down per machine.

There is a feature in Azure Migration called Dependency visualization. Dependency visualization will map out the dependencies between servers and applications to help point out any potential issues up front. This feature leverages Service Map within OMS. In order for Service Map to pick up the dependencies on the machines we need to have the OMS MMA agent and the Service Map dependency agent installed on them. This has to happen even before they migrate.

The following screen shows the MMA agent and dependency agent install steps.

They way to access the dependency visualization screen is to drill down into a group and then click on View dependencies button as shown in the following screenshot.

You will be brought to the Service Map dependencies screen where it shows the dependencies to help identify these before migration to Azure.

That concludes this blog post. Hopefully you found the information about Azure Migrations useful and enjoyed this early look overview of the new Azure Migrate tool.

Before you can monitor something you need a full understanding of what it is that you will be monitoring. Let’s start out by clarifying what PaaS is. There are many facets to cloud and the services that are available in cloud. You also can utilize public cloud, run your own private cloud or utilize a combination of the two known as hybrid cloud. Regardless if you have public, private, or hybrid cloud you can leverage Infrastructure as a Service (IaaS), Platform as a Service, and Software as a Service. Below is an image that has been around for a while that visually explains the main differences between running your own data centers and utilizing cloud.

After viewing the previous image lets dive a little bit deeper into what it is explaining. When you run your own data center/s you are responsible for EVERYTHING all the way down to the networking and storage including monitoring all of that. As you move to the cloud you reduce your administrative overhead releasing that to the cloud vendor.

Most organizations first foray into cloud is to utilize IaaS. With IaaS you take a lift and shift approach of essentially running your existing servers and or new servers in cloud as virtual machines. At this layer you no longer have to worry about and manage the hypervisor, servers, physical storage, and physical networking. At the IaaS layer you still need to manage and monitor what is running on the servers that power workload and applications consisting of things like the OS, middleware, data and the applications. You also manage and monitor software defined storage and networking.

As organizations move to PaaS in cloud you release even more to the cloud vendor reducing even more administrative overhead. Also with PaaS the cost of the cloud services decreases. With PaaS you are responsible for the applications and data. You no longer need to worry about maintaining the administrative tasks of the applications, middleware or the OS.

Let’s zero in on SQL as a service in the cloud. With traditional SQL you had to properly scope and size the server properly, ensure you have enough storage space, split data, logs etc. After that you would need to plan and make SQL highly available, tune a SQL server for performance, maintain it and more. With PaaS the majority of this goes away. In fact with PaaS there is no SQL server/s to manage anymore. With PaaS when developers or anyone in IT need a SQL database they simply go spin it up. IT can still put controls in place such as policy and governance standards that are essentially boundaries that the consumer of the service needs to stay within however it is all self-service.

Now even though SQL databases can be spun up by consumers on their own and the SQL servers are managed by the cloud vendor (Microsoft). Now you would think in a cloud PaaS model you no longer need to monitor as there is no SQL server/s to administer. This is simply not true and we will get more into the monitoring aspect more later on in this post.

Applications running in Azure are typically made up of multiple PaaS services and sometimes a PaaS service itself will have dependencies on other PaaS services. An example of this can be seen in the following Application Map. This shows that PaaS services have many moving parts across multiple parts and can be complex.

With PaaS components that make up applications it is important not to just monitor the components but also the application itself.

Why Monitor PaaS?

Most folks automatically think that they don’t need monitoring of PaaS because they assume without servers and high availability they don’t need to. This simply is not true. Below is a list of reasons of why it is important to monitor PaaS.

Overall when it comes to PaaS best practice is to move away from the old ways of thinking and methods for monitoring servers and on-premises infrastructure and move to a focus of monitoring the business applications.

Understanding the monitoring framework in Azure

Next up let’s take a look at the framework of monitoring in Azure. This will help you to better understand what is possible and how the monitoring tools plug into this framework. There are three main areas of data that is generated by Azure services that can be leveraged in monitoring. These sit across IaaS and PaaS services. These areas are:

Diagnostic

Logs emitted by an Azure resource that provide rich, frequent data about the operation of that resource.

The types of monitoring data sit at different layers on IaaS and PaaS. On IaaS the application logs and metrics come directly out of the application. Diagnostic logging sits across the application and OS layer while metrics sit across the OS layer and VM layer. The activity logging sits at the Azure infrastructure layer.

On PaaS both the diagnostic logging and metrics come from the Azure resources directly. The activity logs again are at the Azure infrastructure layer.

With the diagnostic logs and metrics you can access and configure these via the Azure portal, PowerShell, Azure CLI and many have API.

Diagnostic logs can be sent to OMS log analytics, Event Hubs or Azure storage for other consumption. Metrics can also be sent to OMS log analytics, Event Hubs, Azure storage, and Application Insights. With Metrics you can also fire off alerts and autoscale a service. Alerts can kick off emails, webhooks, and Azure Automation runbooks. The following diagrams visually breakdown what can be done with metric and diagnostic log data.

Options for monitoring Azure PaaS

When it comes to monitoring PaaS Microsoft has many options available. There also are options available from a ton of 3rd party vendors. In this blog post I will only talk about the Microsoft options. Majority of the monitoring tools from Microsoft that can monitor PaaS are cloud based but you also can do some PaaS monitoring via System Center Operations Manager. The cloud options are much faster, easier to onboard and have been built from the ground up with cloud in mind. With Azure you also have out of the box monitoring capabilities on most of the Azure services. For example with a web app in Azure on the overview blade you can see things like data in and out and the Azure Response Time as shown in the following screenshot.

It is great that we get some monitoring out of the box for PaaS services, however this does not help when you are running hundreds+ of services. To handle enterprise scale monitoring of PaaS services you need to centralize the monitoring and that is where the monitoring solutions come in. Microsoft has 4 cloud based monitoring tools to help centralize your Azure monitoring. These tools are able to scale as needed without any hard limits. SCOM is a 5th monitoring tool that can monitor Azure. SCOM is on-premises only though. Here is a screenshot of the various tools minus SCOM:

Here is an example custom PaaS monitoring dashboard in Azure combining widgets from the various monitoring tools:

Now let’s dive into what each tool is and an example of when and how you would use them to help monitor Azure PaaS services.

Application Insights is a Application Performance Monitoring (APM) solution used to monitor applications all the way down to the code. Application Insights is typically used for web apps and other Azure PaaS services to detect, triage, and diagnose the root cause of issues. Application Insights gives you the ability to monitor many things about your applications such as availability, metrics like data coming in and out, dependency mappings through application map, performance data, and even live streams of data points. The following screenshot is an example of a web app in Application Insights.

The following screenshot is an example of an availability test summary chart in Application Insights. It is a ping test pointed to a URL. It gives you the % of the apps availability, the successful tests and failures.

With the availability ping test you have control over a bunch of options such as the frequency, success criteria, any needed alerts upon failures, and the ability to select the locations the test runs from.

Utilize Application Map in Application Insights to discover visually which parts of the application are unhealthy. For the parts that are not healthy drill down using Application Insights to pinpoint the root cause of the errors.

OMSstands for Operations Management Suite. OMS is goes beyond just a tool that can be used for monitoring. It is a suite that also provides, backup, DR, automation and security. It extends to on-premises and it can monitor both IaaS and PaaS. OMS is a platform and has something called solutions. Solutions are used to extend the functionality of OMS. The solutions are packaged management scenarios. I am not going to list out or dive into all of the solutions available for OMS here. Solutions can be found directly in OMS or from the Azure Marketplace. There are a bunch of OMS solutions that can be used to help monitor and gain insight into your Azure PaaS services. The following screenshot has some of the PaaS related solutions that are available for OMS.

In the previous screenshot the OMS solutions with the white background can be found in the Azure Marketplace while the other OMS solutions will be found directly in OMS. More and more solutions are being added to OMS and the Azure Marketplace all the time.

Below is a screenshot of the Azure Web Apps Analytics OMS solution used to gain insight into an Azure web app/s.

Below is a screenshot of Azure Storage Analytics OMS solution from the Azure Marketplace used to monitor and gain insight into Azure storage.

OMS example use case for monitoring Azure PaaS:

Front end application can sometimes connect to a SQL database; and sometimes it cannot. Suspected cause is SQL timeout.

Utilize the Azure SQL Analytics to drill-down into SQL timeouts that have occurred on databases.

Azure Monitor provides a consolidated place for monitoring data from Azure services and base-level infrastructure metrics/logs from Azure services. It is typically used to track performance, security, and identify trends on Azure services. Azure Monitor brings (OMS) log analytics, application insights, and even network watcher into one place. Azure Monitor is still a relatively new service in Azure and it is still taking shape. Azure Monitor does offer some data that (Application Insights and OMS do not). The data you cannot get in OMS and Application Insights includes the history of Azure service issues, planned maintenance, health advisories, health history, and Azure activity logs.

An example use case for using Azure Monitor to help monitor Azure PaaS is:

Need a report of all services issues for a specific region for the past 3 months.

Utilize health history in Azure Monitor to pull a list of all service issues for a specific region from the past 3 months. This example can be seen in the following screenshot.

The following screenshot shows the following areas in Azure Monitor that have important Azure monitoring data.

Azure Monitor also has the ability to integrate with many 3rd party solutions that are used by DevOps folks today. The following screenshot is a group of 3rd party integrations that are available for Azure Monitor.

SCOM can be utilized if you want to monitor Azure resources from on-premises you can utilize SCOM for this. There is a management for Azure. There also is a SCOM management pack for Azure Stack. The SCOM management pack for Azure Stack is used to monitor Azure Stack’s fabric. In order to monitor Azure Stack’s IaaS and PaaS you would use the Azure management pack pointing it to your Azure Stack enviroment. The Azure management pack can monitor the availability and performance of Azure resources that are running on Microsoft Azure via Azure REST APIs.

Azure services that can be discovered and monitored with the Azure SCOM management pack.

Below is a diagram of how the health rolls up in the Azure SCOM management pack.

Microsoft has built an ITSM connector in OMS. This new ITSM connector can connect to many ITSM solutions out there. The ITSM solutions it can connect to are:

System Center Service Manager (SCSM)

Cherwell

ServiceNow

Provance

This new ITSM connector is bi-directional meaning work items can flow from the ITSM solution into OMS and OMS can create work items in the ITSM solution such as incidents, alerts, and events. Hopefully in the future OMS could be used to populate a CMDB and even create application maps from OMS’s Service Map.

I wanted to give this a test run with a test Cherwell instance that I have. There is official documentation for the integrations. The documentation is good however after setting this up I did find that there could be a few more steps spelled out as well as screenshots with the Cherwell piece.

Needed settings from Cherwell:

Before you set the connection in OMS go and get the information you will need. So you will need a username and password of an account that has access to Cherwell, the Cherwell URL, and a Cherwell Client ID.

If you don’t know your Cherwell URL you can get this from the Cherwell client console. Launch Cherwell.

Before you login you can edit the connection to see the URL as shown in the screenshot. You will want to copy this to use in the OMS ITSM connector setup.

Next we need to generate the Client ID. The Client ID is basically a generated string called the client key used for connecting to Cherwell’s API. To get this client ID Launch the Cherwell Administrator console.

Login and click on Security and then Edit REST API client settings.

A window will pop up and you will need to click on the green plus to create a new one. Give it a name and copy out the Client Key.

Copy this as you will need it later.

Setup in OMS:

Next log into OMS and add the ITSM Connector preview. It is shown in the screenshot below.

After this has been added go to your OMS settings screen click on Connected Sources>ITSM Connector and then click on Add New Connection.

Select Cherwell for the connection type add in your Cherwell settings and save it. If everything worked your OMS is now connected to Cherwell.

Exploring the ITSM Connector:

Next let’s check things out in OMS. Before I did that I first went and created a new incident so I could see this flow over into OMS. So I created the following over in Cherwell:

After doing that I went back into OMS and kicked off a sync because I did not want to wait.

The connector picked up my new incident right away. You can see the dashboard ITSM tile has 2 incidents.

After clicking into this I am brought to the full ITSM dashboard. I then clicked on the Incident tile.

I was then brought to the incident dashboard and I could see the new incident I created.

I clicked on the new incident and it brought me to the OMS search with the details of the incident. Very cool!

I am excited to see cool stuff like this in OMS and integration with many ITSM tools. Look out for more blog posts in the future about ITSM Integration in OMS as well as in Azure Stack.

Planning for protection as a part of an IT Service Continuity plan often takes into consideration backup of applications and data as well as restore. But what about security?

When planning for protection of applications and data in your environment security should right up there in the forefront. “Backup Security” should be a key part of the plan.

Security in the context of backup can be thought of #1 as securing the backups, and #2 backups being used as an added measure for security breach mitigation. Let me break this down further.

In regards to securing backups you want to do things like encrypt backup data as it travels offsite, encrypting backup data at rest, being able to protect encrypted data, requiring security pins or further authentication of admins and more.

In regards to backup as an added measure for security backup becomes a direct part of Security planning in organizations. Sometimes when security measures fail backups are the only thing that can save you as a last resort. Backups are commonly becoming a way to recover from ransomware attacks as an alternative to paying the hackers. Here is a real world example.

Recently an unnamed hosting providers entire data center became hostage to a ransomware attack. This hacker got in due to a mistake of one of the system admins (more on how to protect at this level later) and basically had full domain admin rights to everything. Keep in mind majority of the servers in this scenario are for customers.

In this case the hosting provider had two choices. Option #1 go to the dark web via a tor network and pay a ton of money in bitcoin for the decryption key. Option #2 Restore everything from offsite backups and pray.

This hosting provider went for option #2 and thank goodness it worked. In this case if it weren’t for a solid offsite backup solution this hosting provider would have been up a creek without a paddle.

It is becoming more common that ransomeware will actually target backups because these are a high target and hackers understand this is a last resort for companies to save themselves. If the backups are deleted there is no other choice but to pay the ransom. This raises the security level of the backups. Administrative actions on backups need an extra layer of security.

Microsoft Business Continuity products help with not only protection but also security. These products consist of System Centers Data Protection Manager (DPM) and Operations Management Suites Azure Backup (AB) and Azure Site Recovery (ASR). In this post I am only going to touch on DPM and AB.

Some exciting things have been happening with Azure Backup and Data Protection Manager to ensure security is front and center as a part of your enterprise backup solution. Microsoft’s goal with the backup security is to provide prevention, alerting, and recovery.

Just yesterday DPM update rollup 12 for 2012 and update rollup 2 for 2016 was announced. Along with UR2 comes some enhanced security features for DPM. These will be called out later in this blog post. Microsoft has rolled out some great security features to both across hybrid clouds. I will go ahead and break these down.

– Azure Backup –

Encrypted backup data at rest
Described in DPM section.

Security PIN
With Azure Backup you can require a security pin for sensitive operations such as removing protection, deleting data, or changing other settings in Azure Backup itself such as changing a Passphrase.

Azure Backup also has some other security measures in place like a minimum retention range to ensure a certain amount of backup data is always available and notifications upon critical operations to subscription admins or others as specified.

NOTE: These security features are now also available in DPM with the UR’s (UR 12 for 2012 and UR2 for 2016) announced yesterday. When an administrator changes the passphrase, or delete backup data, you need to enter the PIN if you have Enhanced Security Enabled. Also, there is a minimum retention range of 14 days for cloud protected data that is deleted.

MFA
MFA is Multi-Factor Authentication. Microsoft has MFA available as a part of Azure Active Directory. Within Azure Backup you can configure it to require MFA of admins when performing critical operations. By enabling MFA you would then ensure via authentication from a second device usually physical to the user that they are who they say they are.

NOTE: When you enable security settings they cannot be disabled.

Ransomware attacks
Described in DPM section.

– Data Protection Manager –

Backup data encrypted during offsite transfer
When data is sent from DPM to Azure Backup it is encrypted before it even leaves your four walls. Data is encrypted on the on-premises server/client/SCDPM machine using AES256 and the data is sent over a secure HTTPS link.

Encrypted backup data at rest
Once backup data is on Azure it is encrypted at rest. Microsoft does not decrypt the backup data at any point. The customer is the only one with the encryption key that can decrypt the backup data. If this key is lost not even Microsoft can decrypt your backup data. This is very secure.

Protection and recovery of encrypted computers
The release of Hyper-V on Windows Server 2016 included a new feature known as Shielded virtual machines (VM’s). This feature essentially utilizes Virtual Trusted Platform Module (vTPM) technology and BitLocker to encrypt a VM to encrypt virtual machines at the virtual layer. This means if a VM is physically copied off a Hyper-V host whoever has the VM will not be able to get to the data on the virtual hard drive.

With the release of DPM 2016 it supports protecting Shielded VM’s. DPM can protect Shielded VM’s regardless if they are VHD or VHDX. This is great news because as a secure organization you should want to encrypt your virtual machines and DPM can protect them. This gives you an added layer of security on top of having backups.

Ransomware attacks
In today’s world ransomware attacks are a common thing. These type of attacks are targeted at small, medium, and large enterprise businesses. No company is too small or too big to be put in the crosshairs of ransomware attacks. A well-known attack is Cryptolocker.

As mentioned before in this blog post backups are an alternative to paying the ransom of a ransomware attack. They key here is to ensure you have a solid offsite backup in place such as Azure Backup. Having that offsite backup will ensure you can get your data back even if the ransomware attack get ahold of your onsite backup data.

I even go as far as to recommend sticking to the 3-2-1 rule (3 copies of backup data 2 offsite and 1 onsite). This way if something happens to one of your offsite copies of data you have another one. It may seem overkill to have 2 offsite copies but you would be surprised how often offsite backup data is accidently destroyed.

So there you have it. Security is a critical part of any backup solution. It is clear that Microsoft realizes this based on the security enhancements they have made to both Azure Backup and Data Protection Manager 2016. Their goal is to ensure both backup solutions are enterprise ready. I have been working with DPM for years and Azure Backup as soon as it came out. I know the team behind these products have a lot of new features and functionality planned for the future of these products and I am looking forward to it.

I wanted to monitor my Azure Stack environment with OMS. This would include only the Azure Stack fabric servers and the host. I did not want to manually install the OMS agent on all of these servers especially since the Azure Stack fabric is a set of known servers. So I decided to put together a quick PowerShell script to handle the install of the OMS agents including the workspace ID and key. Here are details for the script:

<#

.SYNOPSISThis script can be used to install OMS agents on all of the Azure Stack Fabric servers. This has been tested with TP2.

.DESCRIPTIONThis script can be used to install OMS agents on all of the Azure Stack Fabric servers. This has been tested with TP2. This script can be run from PowerShell ISE or a PowerShell console. It is recommended to run this from an elevated window. This script should be run from the Azure Stack host. Ensure you are logged onto the Azure Stack host as azurestack\azurestackadmin. This script allows you to input your OMS workspace ID and key. The Azure Stack Fabric servers that this script will attempt to install on is:

“MAS-Con01”,

“MAS-WAS01”,

“MAS-Xrp01”,

“MAS-SUS01”,

“MAS-ACS01”,

“MAS-CA01”,

“MAS-ADFS01”,

“MAS-ASql01”,

“MAS-Gwy01”,

“MAS-SLB01”,

“MAS-NC01”,

“MAS-BGPNAT01”

Fabric servers can be added or removed from the array list if desired. The script will look for the OMS agent (MMASetup-AMD64.exe) in C:\OMS\ on the Azure Stack host. Ensure you create an OMS folder on your Azure Stack host and download the OMS agent to it. This script also copies the OMS agent to C:\Windows\Temp on each Fabric server. Ensure there is enough free space on the C drive on all of your fabric servers.

.PARAMETER OMSKeyThis is the OMS API key for your OMS workspace. You can use the primary or secondary key. These keys can be found in the OMS portal at:https://mms.microsoft.com >> Overview >> Settings >> Connected Sources >> Windows Servers

To kick off the script run from PowerShell ISE or a PowerShell console. If you run from ISE you will be prompted for the workspace ID and the key. If you run from a PowerShell console run this syntax to kick it off:

Recently the Operations Management Suite (OMS) team at Microsoft announced the private preview of Service Map in OMS formally known as Application Dependency Map. Service Map has been a long awaited feature in OMS. Service Map is a feature that is a part of OMS that discovers and maps Windows & Linux app and system dependencies. Service Map displays these dependencies in application maps within OMS. Service Map did not start with OMS. It actually started as a standalone product named Fact Finder and later was integrated with SCOM. The integration of FactFinder with SCOM allowed Bluestripe to automatically create Distributed Applications in SCOM. Well Microsoft acquired BlueStripe and the rest is history.

In this post I will set out to explore and break down Service Map, how it is installed, info about the agent, how it works, key points about it, how the data flows and more. NOTE:Click on any of the images in this post to display larger in a new window. Also this post is my first effort in taking one of my PowerPoint’s and converting into a post! The following graphic describes some of the benefits of having application maps including in your monitoring solutions along with information about FactFinder:

Now let’s take a look at what Service Map does and how it looks.

Now let’s take a look at one of the Service Maps aka Application Maps in OMS. Notice on the left hand side the breakdown of the interface. In Service Map there is a focus machine in the center. There are front end and back end connections into that focus machine. These are the dependencies flowing in and out of the focus machine giving the mappings. Notice on the left-hand side you can control the time controls and select either a Windows or Linux machine from the list. Finally, on the left-hand side are the details of the current selection. The current selection can be a machine or process.

Also notice that SM integrates with Change Tracking, Alerts, Performance, Security, and updates. What this means is that when you have a focus machine selected you can click on the corresponding solution on the right hand. When you click on the solution i.e. updates or security the update or security dashboard widget will be shown and you can drill down from there for further detail.

A common question that comes up when discussion Service Map is how does it work. The following graphic displays the process from the solution add to the actual mapping within OMS.

Other key information about Service Map is detailed in the following graphics.

The next graphic looks at deploying the SM agent and locations for logs. The process is as simple as downloading and installing the agent from OMS.

Here is some more critical information you need to know about the SM agent.

This next graphic details how Service Map dependency data flows into OMS.

At this current time Service Map supported Operating Systems at this time are:

Windows

Linux

Windows 10

Windows 8.1

Windows 8

Windows 7

Windows Server 2016

Windows Server 2012 R2

Windows Server 2012

Windows Server 2008 R2 SP1

Oracle Enterprise Linux 5.8-5.11, 6.0-6.7, 7.0-7.1

Red Hat Enterprise Linux 5.8-5.11, 6.0-6.7, 7.0-7.2

CentOS Linux (Centos Plus kernel is not supported)

SUSE Linux Enterprise Server 10SP4, 11-11SP4

Service Map’s computer and process inventory data is available for search in OMS Log Analytics. This is very cool as the log analytics and searching capability in OMS is powerful and most important very FAST. Having application components, service dependencies, and supporting infrastructure configuration data at your fingertips through the log analytics gives you a powerful troubleshooting and forensics tool. I am sure over time the query capabilities will be expanded to include even more.

On your phone you can search Google Play for Microsoft OMS or click this link Operations Management Suite to find the app. Go ahead and install it.

Once installed you will find it with your other apps.

You can also place a shortcut to it on one of your main screens.

The first time you launch it you will need to either sign in or sign up.

Here is a screenshot of the sign in screen.

After you are logged in you need to select your workspace. You can see that I have 3 workspaces. Yes only a true geek would have multiple workspaces in OMS. LOL

After selecting your workspace you will have a similar look and feel to the web based version of OMS. You will also notice 3 main areas Dashboard, Overview, and Search. The first one you will land on is Dashboard. To access the other 3 main areas just scroll to the right. NOTE: I did not see a way to add solutions to OMS from the mobile app. You will need to do this from the web application itself.

The Dashboard view is equal to My Dashboard in the full OMS web application. So whatever you added to your My Dashboard is what you will see here.

Android OMS App

Full OMS Web Application

Now if we go the Overview area this is the same view as we have on the full OMS web application. Overview has the solutions that you have added to your OMS. To see them all just scroll down.

Android OMS App

Full OMS Web Application

You will notice the Searches view also matches what is in “Log Search” in the full OMS web application.