Cloud and Datacenter Management Blog

Microsoft Hybrid Cloud blogsite about Management

Leave a comment

#Microsoft Secure #DevOps Kit of #Azure to Secure your Cloud #Security


The “Secure DevOps Kit for Azure” (will be referred to as ‘AzSDK’ henceforth) is a collection of scripts, tools, extensions, automations, etc. that caters to the end to end Azure subscription and resource security needs for dev ops teams using extensive automation and smoothly integrating security into native dev ops workflows helping accomplish secure dev ops with these 6 focus areas:
1. Secure the subscription: A secure cloud subscription provides a core foundation upon which subsequent development and deployment activities can be conducted. An engineering team should have the capabilities to deploy and configure security in the subscription including elements such as alerts, ARM policies, RBAC, Security Center policies, JEA, Resource Locks, etc. Likewise, it should be possible to check that all settings are in conformance to a secure baseline.
2. Enable secure development: During the coding and early development stages, developers should have the ability to write secure code and to test the secure configuration of their cloud applications. Just like build verification tests (BVTs), we introduce the concept of security verification tests (SVTs) which can check for security of various resource types in Azure.
3. Integrate security into CICD: Test automation is a core tenet of devops. We emphasize this by providing the ability to run SVTs as part of the VSTS CICD pipeline. These SVTs can be used to ensure that the target subscription used to deploy a cloud application and the Azure resources the application is built upon are all setup in a secure manner.
4. Continuous Assurance: In the constantly changing dev ops environment, it is important to move away from the mindset of security being a milestone. We have to treat security as a continuously varying state of a system. This is made possible through capabilities that enable continuous assurance using a combination of automation runbooks, schedules, etc.
5. Alerting & Monitoring: Visibility of security status is important for individual application teams and also for central enterprise teams. We provide solutions that cater to the needs of both. Moreover, the solution spans across all stages of dev ops in effect bridging the gap between the dev team and the ops team from a security standpoint through the single, integrated views it generates.
6. Cloud Risk Governance: Lastly, underlying all activities in the kit is a telemetry framework that generates events capturing usage, adoption, evaluation results, etc. This allows us to make measured improvements to security targeting areas of high risk and maximum usage before others.

The Secure DevOps kit for Azure is here on Github

Provision Security in Subscription

·       Subscription Health Scan

·       Subscription Security Provisioning

·       Subscription AccessControl Provisioning

·       Subscription Activity Alerts

·       Azure Security Center (ASC) configuration

·       Subscription Security – ARM Policy

·       Update subscription security baseline configuration

More information on each item can be found here on Github

Develop Security, Spot Check security via Scripts

• Security Verification Tests (SVT)

Express Route-connected Virtual Networks (ER-vNet)

More information on these items on Github

Deploy securely from VSO Build/Release Pipeline

  • Security Verification Tests (SVTs) in VSTS pipeline
  • Security Verification Tests (SVTs) in Jenkins pipeline (Preview)

The AzSDK contains Security Verification Tests (SVTs) for multiple PaaS and IaaS services of the Azure platform. As we have seen so far, these SVTs can be manually run against one or more target resources held in resource groups or tagged via a {tagName, tagValue} pair. While it is invaluable to run these SVTs periodically from a PS console (to ensure that the subscription and the different resources that comprise your application are in a secure state), a key aspect of dev ops is to be able to automate such tests and integrate them as part of the dev ops workflows and release pipelines. In other words, while checking that SVTs pass in an ad hoc manner is a good practice, it is important to be able to also ensure that security control configuration remains intact in higher environments.
The CICD extensions feature of AzSDK makes automated security configuration enforcement possible by making SVTs available as a Visual Studio Extension in the Marketplace so that engineering teams can run them within build/release pipeline. Once the build/release task is configured, SVTs run against a target deployment in an Azure subscription. Upon completion, SVTs will report the pass/fail status for controls along with aggregate control results. Hereafter, all the different ‘out-of-box’ build/release workflow options from the CICD engine (e.g., VSTS) can be used as ‘next steps’ based on the outcomes of SVTs. (For instance, one can decide whether to fail the release outright or to continue despite failures while sending an email to the build/release owners or to hold progress until someone manually approves, etc. Furthermore, if all SVTs pass in the pre-prod environment, then a release can be ‘promoted’ to prod.)
Outcomes of the SVT execution can also be routed to an OMS workspace configured to receive various events generated by the AzSDK.

More information on Build / Release Pipeline

Periodically scan in production to watch for Drift

Baseline Continuous Assurance

• Overview
• Setting up Continuous Assurance – Step by Step
• Continuous Assurance – how it works (under the covers)
• Update existing Continuous Assurance Automation Account
• Remove Continuous Assurance Automation Account
• Fetch details of an existing Continuous Assurance Automation Account
• Continuous Assurance through central scanning mode (Preview) – Step by Step

More information on Baseline Continuous Assurance here on Github

Single Security Dashboard across DevOps Stages

OMS Solution for AzSDK

  • Overview
  • Components of the AzSDK OMS Solution
  • Setting up the AzSDK OMS Solution (Step by Step)
  • Next Steps
  • Appendix
  • Creating an OMS workspace
  • Testing OMS connectivity
  • Routing AzSDK events to OMS
  • Leveraging other OMS Solutions from the Solutions Gallery

The Alerting & Monitoring features of AzSDK empower dev ops teams with the following capabilities:
a single pane of glass view of cloud security across dev ops stages
visibility to control status for their Azure subscription and critical enterprise/application resources
pre-configured search queries for creating alerts to facilitate action on security drift
Out of the box, these capabilities can be leveraged via the Operations Management Suite (OMS) solution in AzSDK.
However, a dev ops team can equally easily leverage a different system for log analytics (e.g., Splunk) and view the AzSDK control evaluation events in the alternate system. This can be accomplished by using via connectors for Event Hubs or Webhooks in the AzSDK.

More information on Security Monitoring with a Single Dashboard here on Github

Make Data-driven Improvements to Security

Overview Security Telemetry

  • Control Telemetry
  • Organization Level Setup
  •  Local Control Telemetry
  •  Understanding Data in App Insights
  • App Insights Visualization
  •  Usage Telemetry
  • Enable/Disable Usage Telemetry
  • FAQs

The Secure DevOps Kit generates telemetry events from all stages of dev ops. That is, events are generated when an engineer runs a scan ad hoc or when SVTs are run in CICD or subscriptions are scanned via Continuous Assurance (CA). The telemetry can be collected and aggregated across an organization. When combined with other organization metadata (e.g., a mapping of subscriptions to applications or service lines or business groups), this can yield a powerful platform for supporting a data-driven approach cloud risk governance and allow organizations to drive measured and targeted security improvement initiatives in a continuous and incremental fashion (just like the rest of dev ops). The telemetry data from AzSDK can be leveraged in two key ways:
Application Insights based – called Control Telemetry (will be renamed to Org Telemetry soon). There are two ways possible. One, configure it centrally, two, configure it specifically in end-user’s machine
API based – this is a custom solution using WebAPI and SQL to collect events and enrich it with organizational metadata. This lets an organization track and drive adoption and usage of the AzSDK and provides a window into the org’s DevSecOps Maturity. API based telemetry will be release in coming months when we release documents for how organization can customize AzSDK for their needs

More on Security Telemetry you find here on GitHub

Fetch information about various AzSDK components

  • Overview
  • Subscription information
  • Control information
  • Attestation information
  • Host information

This command provides overall information about the AzSDK which includes subscription information (alert/policies/ASC/CA version etc.), security controls information (severity, description, rationale etc.), attestation information (statistics, attestation justification, expiry etc.), host information (AzSDK settings/configuration, AzureRM Context etc.). ‘Get-AzSDKInfo’ command can be used with ‘InfoType’ parameter to fetch information.

More information about Get-AzSDKInfo on Github

Start with Microsoft Azure ARM Templates

Use Microsoft Visual Studio Code to work with JSON ARM Templates and Azure subscription


Hope these Microsoft DevOps Azure Security SDK resources are helpful for your organization.



Cheers James.


Leave a comment

#Microsoft Azure Virtual Datacenter Guidance Whitepaper Available #Cloud #Security #Azure

Overview Azure Virtual Datacenter is an approach to making the most of the Azure cloud platform’s capabilities while respecting your existing security and networking policies. When deploying enterprise workloads to the cloud, IT organizations and business units must balance governance with developer agility. Azure Virtual Datacenter provides models to achieve this balance with an emphasis on governance. Deploying workloads to the cloud introduces the need to develop and maintain trust in the cloud to the same degree you trust your existing datacenters. The first model of Azure Virtual Datacenter guidance is designed to bridge that need through a locked-down approach to virtual infrastructures. This approach isn’t for everyone. It’s specifically designed to guide enterprise IT groups in extending their on-premises infrastructure to the Azure public cloud. We call this approach the trusted datacenter extension model. Over time, several other models will be offered, including those that allow secure Internet access directly from a virtual datacenter.

In the Azure Virtual Datacenter model, you can apply isolation policies, make the cloud more like the physical datacenters you know, and achieve the levels of security and trust you need. Four components any enterprise IT team would recognize make it possible: software-defined networking, encryption, identity management, and the Azure platform’s underlying compliance standards and certifications. These four are key to making a virtual datacenter a trusted extension of your existing infrastructure investment. Central to this model is the idea that your cloud infrastructure has isolation boundaries that can be thought of as your corporate namespace. Think of it as your isolated cloud within Azure. Within this virtual boundary, security controls, network policies, and compliance come together, providing you with an IT infrastructure on Azure capable of securely integrating cloud resources with your existing on-premises datacenter. You can deploy new virtual workspaces in the virtual datacenter much as you would deploy additional capacity to your physical datacenter. These virtual workspaces are self-contained

Environments where workloads can run independently, and workload teams can get workspace specific access. Workspaces enable teams to build solutions and manage workloads with great freedom while adhering to the overall access and security policies defined in the central IT infrastructure. This guide is intended for enterprise IT architects and executives. Using the lens of the physical datacenter, the guide discusses an approach to designing secure, trusted virtual datacenters on the Azure platform. Azure Virtual Datacenter is not a specific product or service but rather a way to think about cloud infrastructures. It offers proven practices and guidance to help smooth your migration to the cloud. At the end of this guide, you can learn about the upcoming Virtual Datacenter Automation guidance. This guidance includes a collection of scripts and Azure Resource Manager templates that will help you build an Azure Virtual Datacenter using the trusted extension model.

You can download this Awesome Microsoft whitepaper Azure Virtual Datacenter here

Leave a comment

UPDATE #Microsoft #Azure, #Cloud, #MSOMS and Enterprise Symbol / Icon Set – Visio stencil


This package contains a set of symbols/icons to visually represent features of and systems that use Microsoft Cloud and Enterprise technologies, including Windows Server, Microsoft Azure and related technologies. Email to provide feedback and suggestions.

MSOMS Visio Icons

Microsoft Operations Management Suite Visio Icons #MSOMS

You can download the Microsoft Azure, Cloud and Enterprise Symbol / Icon Set – Visio stencil here

Leave a comment

Microsoft Azure Stack Single Server POC Deployment part1 #Azure #AzureStack #HybridCloud

Dell PowerEdge R710-240GB-Dual QuadCore 2.26GHz

Dell Power Edge R710 Server for Microsoft AzureStack TP1 POC

Hardware Requirements

These requirements apply to the Azure Stack POC only and might change for future releases.

Component Minimum Recommended
Compute: CPU Dual-Socket: 12 Physical Cores Dual-Socket: 16 Physical Cores
Compute: Memory 96 GB RAM 128 GB RAM
Compute: BIOS Hyper-V Enabled (with SLAT support) Hyper-V Enabled (with SLAT support)
Network: NIC Windows Server 2012 R2 Certification required for NIC; no specialized features required Windows Server 2012 R2 Certification required for NIC; no specialized features required
Disk drives: Operating System 1 OS disk with minimum of 200 GB available for system partition (SSD or HDD) 1 OS disk with minimum of 200 GB available for system partition (SSD or HDD)
Disk drives: General Azure Stack POC Data 4 disks. Each disk provides a minimum of 140 GB of capacity (SSD or HDD). 4 disks. Each disk provides a minimum of 250 GB of capacity.
HW logo certification Certified for Windows Server 2012 R2 Certified for Windows Server 2012 R2

Data disk drive configuration: All data drives must be of the same type (SAS or SATA) and capacity. If SAS disk drives are used, the disk drives must be attached via a single path (no MPIO, multi-path support is provided)

HBA configuration options: 1. (Preferred) Simple HBA 2. RAID HBA – Adapter must be configured in “pass through” mode 3. RAID HBA – Disks should be configured as Single-Disk, RAID-0

Supported bus and media type combinations

  • RAID SSD (If the media type is unspecified/unknown*)
  • SAS SSD + SAS HDDExample HBAs: LSI 9207-8i, LSI-9300-8i, or LSI-9265-8i in pass-through mode
  • Sample OEM configurations are available.
  • * RAID controllers without pass-through capability can’t recognize the media type. Such controllers will mark both HDD and SSD as Unspecified. In that case, the SSD will be used as persistent storage instead of caching devices. Therefore, you can deploy the Microsoft Azure Stack POC on those SSDs.

Deploy Azure Stack POC

  • Before you deploy, prepare the Azure Stack POC machine and make sure it meets the minimum requirements.
    1. Install Windows Server 2016 Datacenter Edition Technical Preview 4 EN-US (Full Edition).
    2. Download the Azure Stack POC deployment package to a folder on your C drive, (for example, c:\AzureStack).
  • Run the Microsoft Azure Stack POC.exe file.



This creates the \Microsoft Azure Stack POC\ folder containing the following items:

  • DeployAzureStack.ps1: Azure Stack POC installation PowerShell script
  • MicrosoftAzureStackPOC.vhdx: Azure Stack data package
  • SQLServer2014.vhdx: SQL Server VHD
  • WindowsServer2012R2DatacenterEval.vhd
  • WindowsServer2016Datacenter.vhdx: Windows Server 2016 Data Center VHD (includes KB 3124262)


Important: You must have at least 128GB of free space on the physical boot volume.

  • Copy WindowsServer2016Datacenter.vhdx and call it MicrosoftAzureStackPOCBoot.vhdx.
  • In File Explorer, right-click MicrosoftAzureStackPOCBoot.vhdx and click Mount.
  • Run the bcdboot command:

bcdboot <mounted drive letter>:\windows




  • Reboot the machine. It will automatically run Windows Setup as the VHD system is prepared.
  • Configure the BIOS to use Local Time instead of UTC.
  • Verify that four drives for Azure Stack POC data:


  • Are visible in disk management
  • Are not in use
  • Show as Online, RAW
  • Verify that the host is not joined to a domain.
  • Log in using a local account with administrator permissions.
  • Verify network connectivity to



Important: Only one NIC is allowed during the deployment process. If you want to use a specific NIC, you must disable all the others.

Run the PowerShell deployment script

  1. Open PowerShell as an administrator.
  2. In PowerShell, go to the Azure Stack folder location (\Microsoft Azure Stack POC\ if you used the default).
  3. Run the deploy command:

AzureStack Deploy script cmdI’m running the script with Proxy settings.


Deployment starts and the Azure Stack POC domain name is hardcoded as azurestack.local.



  1. At the Enter the password for the built-in administrator prompt, enter a password and then confirm it. This is the password to all the virtual machines. Be sure to record this Service Admin password.AzureStack19
  2. At the Please login to your Azure account in the pop-up Azure authentication page, hit any key to open the Microsoft Azure sign-in dialog box.AzureStack20
  3. Enter the credentials for your Azure Active Directory Account. This user must be the Global Admin in the directory tenantAzureStack21
  4. Back in PowerShell, at the account selection confirmation prompt, enter y. This creates two users and three applications for Azure stack in that directory tenant: an admin user for Azure Stack, a tenant user for the TiP tests, and one application each for the Portal, API, and Monitoring resource providers. In addition to this, the installer adds consents for the Azure PowerShell, XPlat CLI, and Visual Studio to that Directory Tenant.AzureStack22
  5. At the Microsoft Azure Stack POC is ready to deploy. Continue? prompt, enter y.AzureStack24
  6. The deployment process will take a few hours, during which several automated system reboots will occur. Signing in during deployment will automatically launch a PowerShell window that will display deployment progress. The PowerShell window closes after deployment completes.AzureStack25
  7. On the Azure Stack POC machine, sign in as an AzureStack/administrator, open Server Manager, and turn off IE Enhanced Security Configuration for both admins and users.

There are two ways to log in to the Azure Stack POC.

Log in as a service administrator

A service administrator manages resource providers, tenant offers, plans, services, quotas, and pricing.

  1. Log in to the Azure Stack POC physical machine.AzureStack25a
  2. Double-click the AzureStack.local.rdp desktop icon to open a Remote Desktop Connection to the client virtual machine. This automatically uses the AzureStack\AzureStackUser account that was created by the deployment script. Use the admin password you gave in step 5 of the script process at the Enter the password for the built-in administrator prompt.AzureStack28
  3. On the ClientVM.AzureStack.local desktop, double-click Microsoft Azure Stack POC Portal icon (https://portal.azurestack.local/).AzureStack29
  4. Log in using the service administrator account.AzureStack30Click on Accept


Log in as a tenant

Tenants provision, monitor, and manage services that they subscribe to, like Web Apps, storage, and virtual machines. A service administrator can log in as a tenant to test the plans, offers, and subscriptions that their tenants might use. If you don’t already have one, Create a tenant account before you log in.

  1. Log in to the Azure Stack physical machine.
  2. Double-click the AzureStack.local.rdp desktop icon to open a Remote Desktop Connection to the client virtual machine. This automatically uses the AzureStack\AzureStackUser account that was created by the deployment script. Use the admin password you gave in step 5 of the script process at the Enter the password for the built-in administrator prompt.
  3. On the ClientVM.AzureStack.local desktop, double-click Microsoft Azure Stack POC Portal icon (https://portal.azurestack.local/).
  4. Log in using a tenant account.

RDP may restrict how many users can access the physical Microsoft Azure POC host. To enable multiple users, see Enable multiple concurrent user connections.


All Cloud

Next blogpost will be about Configuring Microsoft Azure Stack part 2