In part two of this multi part blog series, we covered the creation and configuration of a GitHub account, to host a GitHub repository for a Quick Start template, and then we examined Visual Studio Code integration with Git and lastly we pushed commits to a remote repository on GitHub. In the final post, we will modify and deploy sample and custom template and parameter JSON files. If you missed Part I and Part II, please make sure to check them here Part I and Part II before you continue with the last part.

In part one of this multi part blog series, we explained the benefits of Azure Resource Manager and resource groups in Azure V2 versus the Service Management API in Azure V1, then we looked in depth at JavaScript Object Notation (JSON) Quick Start templates. In the second part, Part II: we will create and configure a GitHub account, if you don’t already have one, to host a GitHub repository for a Quick Start template, and lastly we will examine Visual Studio Code integration with Git and push commits to a remote repository. In the final post, we will modify and deploy sample/custom template and parameter JSON files. If you missed Part I, please make sure to check it here before you continue with this post.

Applications that are deployed in Microsoft Azure often comprise different but related cloud resources, such as virtual machines, web applications, SQL databases, virtual networks among others. Before the introduction of Azure Resource Manager (Azure V2), it was necessary to define and provision these resources imperatively. However, Azure Resource Manager gives you the ability to define and provision these resources with their configuration and associated parameters declaratively in a JavaScript Object Notation (JSON) template file, known as an Azure Resource Manager template.

In part three of this multi-part blog series, we covered how to configure OMS to collect data through integration with System Center Operations Manager (SCOM), and through direct connections to individual servers. We also covered how Microsoft Operations Management Suite uses Solutions to deliver insights into your log data by providing a cost-effective, all-in-one cloud management solution so you can better protect guest workloads in Azure, AWS, Windows Server, Linux, VMWare, and Open Stack.

In part two of this multi part blog series, we covered how to configure OMS to collect data through integration with System Center Operations Manager (SCOM), and through direct connections to individual servers. We also covered how Microsoft Operations Management Suite uses Solutions to deliver insights into your log data by providing a cost-effective, all-in-one cloud management solution so you can better protect guest workloads in Azure, AWS, Windows Server, Linux, VMWare, and Open Stack

In part one of this multi-part blog series, we covered how to establish a Microsoft Operations Management Suite environment; in the second part, Part II, we will discuss how to get started with Microsoft Operations Management Suite and we will introduce OMS solutions. If you missed Part I, please make sure to check it here before you move on to Part II.

In this series of blog posts, we will show you how to get started with Microsoft Operations Management Suite (OMS) so that you can protect your heterogeneous environments, respond proactively to changing business needs and simplify IT management – all from a single portal with no infrastructure to maintain. This post will also show you how Microsoft Operations Management Suite delivers immediate, actionable insights into your log data by providing a cost-effective, all-in-one cloud management solution so you can better protect guest workloads in Microsoft Azure, AWS, Windows Server, Linux, VMWare, and Open Stack.

Warning: This article is written with information related to Windows Server 2016 Technical Preview 4. In part one of this multi part blog on How to Configure Storage Replication in Windows Server 2016, we covered an introduction into Storage Replica which is a new feature introduced in Windows Server 2016, and we covered step by step the implementation of Windows Volume Replication (Server-to-server). In this follow up post, we are going to cover the implementation of volume replication with stretch cluster. This type of cluster features uses Asymmetric storage, two sites, two sets of shared storage and uses volume replication to ensure that data is available to all nodes in the cluster.

Warning: This article is written with information related to Windows Server 2016 Technical Preview 4. Storage Replica is a new feature introduced in Windows Server 2016 that enables storage-agnostic, block-level, synchronous replication between servers for disaster recovery, as well as stretching of a failover cluster for high availability. Synchronous replication enables mirroring of data in physical sites with crash-consistent volumes ensuring zero data loss at the file system level. Asynchronous replication allows site extension beyond metropolitan ranges with the possibility of data loss.