Have you been in a situation where an Azure Resource Manager (ARM) template with Azure Blueprint is the only option available for Infrastructure as Code (IaC) deployment? Have you realized that certain operations during deployment are not possible with an ARM template? Have you been in a situation that PowerShell or Azure CLI can get the job done, but there is no way to inject that script into the ARM template? Maybe you have felt like ARM-disabled at this time. If you answered yes to at least one of the situations, this blog is for you. Let’s dive into a cool feature, ‘Deployment Scripts in ARM Templates,’ which helped me to overcome these hurdles!

Azure managed disks by default have Server-Side Encryption (SSE) with Platform Managed Key (PMK), identified as SSE + PMK. I had the requirement to encrypt VM’s (Windows or Linux) with either SSE or Azure Disk Encryption (ADE) with Customer Managed Key (CMK). CMK provides an additional security layer as the customer can manage the keys, and they can rotate the keys periodically. Both types of encryptions require an RSA-based Key Vault key. While you can implement an SSE and ADE with CMK can using PowerShell and Azure CLI, I only had an ARM template deployment option. An ARM template has the functionality to create key vault secrets but cannot create key vault keys. For SSE encryption, a ‘disk encryption set‘ needs to be created. In the automated deployment, the key vault key and disk encryption set must exist for the virtual machine deployment to consume the key vault key to encrypt the VM and OS/Data disks.

The following picture shows default encryption on a VM managed disk – SSE with PMK (by default):

VM Disk

Choosing encryption types is based on customer requirements. Azure offers SSE + PMK as a default feature, which provides encryption at rest. Either SSE + CMK or ADE + CMK can be applied on top of default encryption. For more information to understand SSE and ADE, please read this great blog post. It explains fundamental differences between these types of encryptions when to choose one over the other, and the caveats to watch out after the encryption is applied.

Microsoft explains the difference between SSE and ADE by stating that Azure Disk Encryption leverages the BitLocker feature of Windows to encrypt managed disks with Customer-Managed Keys within the guest VM. Server-Side Encryption with Customer-Managed Keys improves on ADE by enabling you to use any OS type and images for your VMs by encrypting data in the Storage service.

The following screenshot shows Managed disk SSE + CMK encryption implemented via ARM template at the time of VM creation using Disk Encryption Set:

SSE + CMK encryption

The following screenshot shows Managed disk ADE + CMK encryption implemented via ARM Custom Extension:

ADE + CMK

The following screenshot shows ARM Custom Extension for ADE + CMK encryption:

ARM Custom Extension

The following screenshot shows how Key Vault secret is used by writing ‘Encrypted BEK’ for ADE + CMK encryption:

Key Vault secret

While I learned more about disk encryption, I was still contemplating disk encryption options in the ARM template. Microsoft ARM template team announced this cool new feature, deployment scripts! This was announced at the MS Build Event, which you can view here for more information. Deployment scripts are a new resource in ARM that can run PowerShell and Azure CLI scripts within the ARM template! The feature came in time to resolve ARM deployment impediments. The implementation creates a storage account to copy the script from the ARM template into file share and run an Azure container instance to execute the script. A user-managed identity is created and given permission to the resource group and added to key vault access policies. The script is executed as this user-managed identity. At this time, no system assigned identity is supported. The deployment scripts resource is available in both Azure public and government, wherever Azure container instances are available. Both the storage account and container instances are deleted after successful deployment scripts resource deployment.

The following screenshot is the deployment scripts ARM template resource:

Deployment Scripts ARM template

The following screenshot shows a container instance and storage account resources used by deployment scripts. They will be deleted after successful deployment script execution. The user managed identity is created in an ARM to execute the deployment script. The deployment script creates Key Vault, Keys in key vault, and Disk Encryption Set.

Container Instance

Additional features in deployment scripts resource:

  • The scripts can be either embedded inline or referenced from a location accessible from deployment.
  • The output from deployment scripts resource can be consumed/referenced by other resources in the deployment
  • An existing storage account can be referenced, and that storage account will be used instead of creating a temporary storage account.
  • Any task done via PowerShell and Azure CLI can be done in the deployment scripts, such as disk encryption, the storage account can be encrypted with CMK via PowerShell in deployment scripts.

Security considerations:

  • Deployment scripts create Standard_LRS storage account SKU, and if a Geo-Redundant security policy is enabled then the policy might fail and report. As the storage account gets deleted after the deployment scripts are done, the policy will not be non-compliant.
  • The storage account access should be public when using the existing storage account for the deployment script. This is to allow the script to be copied to file share and by permission for the container, instance to execute the script.
  • The Key Vault firewall needs to be turned off for the deployment scripts to be able to perform operations in key vault key and certificates. But the firewall can be enabled back in the PowerShell after all the work is done.

The following screenshot shows ARM Template Key vault resource, no firewall restriction:

ARM Template

In the following screenshot, I enable firewall access to the key vault in PowerShell script after the tasks are done:

Enable Firewall access

ARM template for SSE + CMK disk encryption:

SSE + CMK is applied when the disk-encryption-type parameter is set to ‘SSE’. If it is ‘ADE’ then no SSE is applied.

SSE + CMK is applied

ARM Template for ADE + CMK Disk Encryption using VM Extension

ARM Template for ADE

In the code example, the newly created Azure key vault key is saved to secrets to be able to access from an ARM template. ARM does not have the functionality to access key vault keys but can access secrets using the template reference parameter, like below.

Template Reference parameter

Instead of using as secrets, another approach to write the key vault key (KeK ID) as deployment scripts output and use that output in the VM ARM template.

The following screenshot shows how to write output from deployment scripts resource in keyvault.json:

Write up output

The following screenshot shows how to consume the output written in deployment scripts resource in vm.json for KeK URL:

Consume the output

For full code access to try using ‘deployment scripts’ in an ARM template to create Key vault keys, disk encryption set, and to encrypt the VM disks with SSE or ADE, please follow the link to get the code.

Once downloaded, follow the steps to test in your environment, Azure Cloud or Azure Government. Update the parameters before deploying:

Connect-AzAccount -Tenant "000000-000-0000-0000" -SubscriptionId "000000-000-0000-0000" -EnvironmentName AzureCloud

# Create Resource Group
$rg = New-AzResourceGroup -Name "deploy-script-rg" -Location "eastus2"

# Create Key Vault with ‘deployment scripts’
New-AzResourceGroupDeployment -ResourceGroupName $rg.ResourceGroupName -TemplateFile "C:\deploymentScriptsARM\keyvault.json" -TemplateParameterFile "C:\deploymentScriptsARM\keyvault.parameters.json"

# Create Virtual Machine with disk encryption
New-AzResourceGroupDeployment -ResourceGroupName $rg.ResourceGroupName -TemplateFile "C:\deploymentScriptsARM\vm.json" -TemplateParameterFile "C:\deploymentScriptsARM\vm.parameters.json"

Additional ARM Templates references:

Happy ARM Templating for IaC!!!

During a recent design session at a client site, our team had the opportunity to participate in something cool. We had the opportunity to create a custom DSL (Domain Specific Language) in YAML for an automation framework we wanted to build. This blog will help provide a high-level overview. The client wants to use Azure Automation to create a self-healing framework for their infrastructure. The environment is a mixture of both PaaS and IaaS, with certain VMs being used to host app and database servers. Unfortunately, because of potential performance issues, it is important to regularly perform healing actions on the environment, which so far is being done manually. Now you may be asking, “Why don’t they use something like Chef or Puppet?”. It is because these technologies were either in the process of being on-boarded or were not available. You may also ask, “Well, if you’re going to use Powershell, just use Powershell DSC!”. While I agree that Powershell DSC is powerful and could potentially power the engine for this application (explained below), DSC itself is not very user-friendly. One of the major factors for this session was to allow any user to edit or read the definitions, and YAML is a much more robust option for usability.

The design session itself was fascinating. I had never spent time creating my own configuration language complete with definitions and structure. It was a great learning experience! I had used YAML briefly when demoing out things like Ansible for personal projects, but never directly to solve an issue. YAML had always been another markup language for me. This usage of it, however, showed me the power of the language itself. The problem that we ended up solving with the below snippet was creating an abstraction layer for Azure Monitor Alerts.

After the session completed, we were left with something like this:
Create and Abstraction Layer

Now what?

We must take this YAML File and convert it into an Azure Monitor Alert. The first problem we ran into is that this file is a YAML File. How can I take these configuration values and convert them to be used in Powershell? Here is where Cloudbase’s powershell-yaml module comes into play. As we all know, Powershell was written on top of and created to be an extension for the .NET Framework, so people at Cloudbase created the wonderful powershell-yaml, a module that is a wrapper around the popular .Net Library YamlDotNet.

With powershell-yaml you can create something like this:
Converting the yaml File

In this example, I am not only converting the yaml file into a JSON file as an example, but I am returning the yaml as a PSObject. I find this much easier to use because of the ease of dot notation.

In this case, you can now reference variables such as this:
Corresponding Powershell cmdlets

I was able to follow up with the corresponding PowerShell cmdlets available in the Az Modules and programmatically create Azure Monitor Alerts using YAML.

The eventual implementation will look roughly like this:
Azure Alerts

Each Azure Alert will trigger a webhook that is received by the Engine that is running in Azure Automation. This Engine will then do all business logic to find out whether the piece of infrastructure in question needs healing. If all the previously defined reasons are true the automation runbook will perform the recovery action.

The exercise itself was eye-opening. It made me much more comfortable with the idea of designing a solution for our specific scenario rather than trying to find out and wait to find the product or framework that would solve the problem for us. Also, this PoC showed me the power of YAML and how it can turn something incredibly monotonous, like configuration values, into something that can be part of your robust solution.

Azure Automation provides credential assets for securely passing credentials between the automation account and a Desired State Configuration (DSC). Credentials can be created directly through the portal or through PowerShell and easily accessed in the DSC configuration. However, there a few disadvantages with storing credentials in an automation account vs. storing credentials in a KeyVault:

  • More fine-grained permissions can be set on a KeyVault – for example, custom access policies can be set for different principals.
  • KeyVault secret values can be viewed in the portal (assuming you have access). Passwords in an automation account credential cannot.
  • In most scenarios, a KeyVault is the “single source of truth”, where all secure assets in a tenant are stored. If you need to access credentials in an ARM template and a DSC configuration, they must be in a KeyVault for use in the ARM template.

In this example, we will walk through a very simple workstation configuration that pulls a username and password from a KeyVault, then passes those parameters into a DSC resource to create a new local user on a target VM.

Prerequisites

  • A Key Vault already provisioned
  • An Automation Account already provisioned
  • The Az.Accounts and Az.KeyVault modules imported into the Automation Account

Permissions

The Automation Connection, or more specifically, the service principal of the automation connection, needs to have at least “Get” selected under Secret permissions in the KeyVault access policies.

Creating the DSC file

These are the minimum set of parameters necessary to extract a username and password from a KeyVault:

param
(
    [Parameter(Mandatory)]
    [string] $keyVaultName,

    [Parameter(Mandatory)]
    [string] $usernameSecretName,

    [Parameter(Mandatory)]
    [string] $passwordSecretName,

    [Parameter(Mandatory)]
    [string] $automationConnectionName
)

The first 3 parameters’ purpose should be self-explanatory. The final parameter, automationConnectionName, is used to establish a connection to Azure. Even though this code is executing in the context of an Automation Account, it is not connected to Azure in the same way as if we had connected using Login-AzAccount or Connect-AzAccount. There are special cmdlets available when running in an automation account that we can use to establish a “full” connection:

$automationConnection = Get-AutomationConnection -Name $connectionName

Note that we are calling Get-AutomationConnection, NOT Get-AzAutomationConnection. The latter command only works when you have already established a connection to Azure. Get-AutomationConnection is one of those special cmdlets available when running in an Automation Account. Conversely, Get-AutomationConnection will not work if the DSC is executing outside the context of an Automation Account. For more information on connections in Azure Automation, refer to https://docs.microsoft.com/en-us/azure/automation/automation-connections

Get-AutomationConnection returns an object containing all the necessary properties for us to establish a “full” connection to Azure using the Connect-AzAccount cmdlet:

Connect-AzAccount -Tenant $automationConnection.TenantID -ApplicationId $automationConnection.ApplicationID -CertificateThumbprint $automationConnection.CertificateThumbprint 

Note that for those of you that aren’t running this in the Azure public cloud (such as Azure Government or Azure Germany), you’ll also need to add an environment switch to point to the correct cloud environment (such as -Environment AzureUSGovernment)

At this point, we can run the az cmdlets to extract the secrets from the KeyVault:

$username = (Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $usernameSecretName).SecretValueText

$password = (Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $passwordSecretName).SecretValue

Full Example Configuration

configuration Workstation
{
	param
	(
		[Parameter(Mandatory)]
		[string] $keyVaultName,

		[Parameter(Mandatory)]
		[string] $usernameSecretName,

		[Parameter(Mandatory)]
		[string] $passwordSecretName,

		[Parameter(Mandatory)]
		[string] $automationConnectionName
	)

	Import-DscResource -ModuleName PSDesiredStateConfiguration

	$automationConnection = Get-AutomationConnection -Name $automationConnectionName
	Connect-AzAccount -Tenant $automationConnection.TenantID -ApplicationId $automationConnection.ApplicationID -CertificateThumbprint $automationConnection.CertificateThumbprint

	$username = (Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $usernameSecretName).SecretValueText

	$password = (Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $passwordSecretName).SecretValue

	$credentials = New-Object System.Management.Automation.PSCredential ($username, $password)

	Node SampleWorkstation
	{
		User NonAdminUser
		{
			UserName = $username
			Password = $credentials
		}
	}
}

Final Thoughts

Remember the nature of DSC compilation – all variables are resolved at compile-time and stored in the resulting MOF file that is stored in the automation account. The compiled MOF is what is actually downloaded and executed on the target Node/VM. This means that if you change one of the secret values in the KeyVault, the MOF will still contain the old values until you recompile the DSC.

Recently, I have been using the new windows terminal to run CMD and PowerShell commands while supporting clients. I wanted to write this blog to help answer some of the questions and issues I had while installing and customizing it.

Note: The New Windows Terminal is in PREVIEW. That means you may experience crashes or features may appear/disappear without warning.

The new terminal has an impressive set of features that I will detail below. These include:

  • Tabbed interface for Command Prompt and Multiple PowerShell versions
  • Support for Unicode characters so you can now use emoji in your scripts!
  • Rich customization options that can be modified to suit your preferences

Install Notes

Prerequisites

The first settings to check is your current version of Windows 10. You can find this by right-clicking Start and selecting System. Scroll down and look at the version you are currently running. You need to be running 1903 or later:

Windows 10 System Setting

Windows 10 System Settings

If you need to update to version 1903 (also called the Windows 10 May 2019 Update) you can open Windows Update by clicking Start, then Typing “Update”. Then click “Check for Update” in the Start menu. This will bring up Windows Update. From there you can click the “Check for Updates” button and apply the latest version. If no version appears you can manually download/install version 1903 here.

Install the New Terminal

Install the Windows Terminal (Preview) from the Microsoft Store. Fire that app up and search for Windows Terminal. Once you find it, click “Get” in the upper right. Ensure you are on a device in which you have logged in to with a Microsoft/Outlook.com/LiveID account. I had an issue with device authorization I had to work through before the store would allow me to download and install the terminal.

Once the install completes, you can start the terminal by clicking Start then typing Terminal. If you are a taskbar die hard (like me) you may also wish to pin the app:

Windows Terminal

The Interface

Once you fire up the terminal, you will immediately notice it looks different from a standard PowerShell or CMD shell. The tabs along the top allow you to run multiple shells in the same session. You can also link to multiple versions of PowerShell by adding additional profiles to the settings JSON file. We will cover the customization of settings in the next section.

Multiple Versions of Powershell

Customization

One of the most exciting features of the new terminal is the ability to customize it. You can set custom background images (yes, even GIFs!). You can also change text color schemes, cursor shape and color, and background opacity.

To access the configuration settings, you need to click the down arrow at the upper right of the terminal. From there click “Settings”:

Terminal Configuration Settings

That will open the profiles.json in your favorite editor. On my system that’s VSCode.

Scroll down to the Profiles section:

Terminal Profile Section

To create your own profile copy and paste the following JSON above an existing profile:

{
"startingDirectory": "%USERPROFILE%",
"guid": "{565ed1db-1474-455e-9d62-cb9fc7eb3f59}",
"name": "PowerShell",
"background": "#012456",
"colorscheme": "Campbell",
"historySize": 9001,
"snapOnInput": true,
"cursorColor": "#FFFFFF",
"cursorShape": "bar",
"commandline": "powershell.exe",
"fontFace": "Courier New",
"fontSize": 12,
"acrylicOpacity": 0.5,
"useAcrylic": false,
"closeOnExit": true,
"padding": "0, 0, 0, 0",
"icon": "ms-appdata:///roaming/pwsh-32.png"
},

From there, we can use this structure to begin our custom profile.

Important: The GUID above must be unique for each profile. You can change one character or use PowerShell Cmdlet New-GUID to generate a completely new GUID. If there are overlapping profile GUIDS, unexpected behavior will result.

Next, let’s look at the implementation details of each customization:

Acrylic Settings

The acrylic setting allows you to set the opacity to the background of the terminal. When the terminal window is in focus, there is a cool translucent effect allowing you to see the windows behind the terminal. When the window is out of focus, the opacity is cranked back up, and the terminal becomes fully opaque once more.

CMD in Focus:

CMD in Focus

CMD Out of Focus:

CMD Out of Focus

Note: If you use a background image, Acrylic needs to be disabled (set to false). As of this writing, acrylic does not support the overlay of a background image.

Background Images

You can add a background image to a specific profile. The image can be static or a GIF. You can add a background image with the addition of the following key/value pair in the profile:

"backgroundImage" : "/aisbackground.jpg",

This will change the default background to the image you have added:

CMD Background Image

Or you can get creative and add a GIF:

"backgroundImage" : "/nyan.gif",

Fun GIF

Note: If you set a GIF as a background, you should also add the following key to the profile containing the GIF:

"backgroundImageStretchMode" : "uniformToFill",

Color Schemes

There are default color schemes included if you scroll down to the Schemes area in the profile JSON. The default names you can use are (Pay attention to the case below, it matters):

  • Campbell (The new default color scheme for Windows Console)
  • One Half Dark
  • One Half Light
  • Solarized Dark
  • Solarized Light

You can modify the Hex values for the existing schemes or copy/paste one of the above and rename/edit it how you see fit.

These color schemes can also be applied to standard CMD console through the Microsoft ColorTool.

Cursor Share and Color

In addition to overall color schemes, you can modify the shape and color of the cursor in your custom profile.

Here are the other options and their settings for cursor shape:

Important: Note the camelCase, once again, these properties are case sensitive.

bar

"cursorShape" : “bar",
Cursor Shape Bar

emptyBox

"cursorShape" : "filledBox",

Cursor Shape emptyBox

filledBox

"cursorShape" : "filledBox",

Cursor Shape filledBox

underscore

"cursorShape" : "underscore",

Cursor Shape Underscore

vintage

"cursorShape" : "vintage",

Cursor Shape Vintage

I also changed the cursor color to the blue from our company style guide:

"cursorColor" : "#0F5995",

Cursor Color AIS

Icon Setting

When you click the down arrow in the new terminal, you will notice a small blank space next to the CMD/Command Prompt shell.

Terminal Icon Setting

This can also be customized. I changed mine to the AIS logo in my custom profiles:

Terminal Custom Icon

To accomplish this, edit the Icon key in the profile as follows:

"icon" : "C:/Users/Clint.Richardson/aisfavicon.png",

Command Line (Target shell):

You may have noticed in the previous section that my choices of PowerShell version also changed. This allows me to run PowerShell 5 which ships with Windows 10. Or the new PowerShell Core 6. I also wanted to add a visual queue to the background image, so I knew when I was using version 6.

PowerShell Version 5

PowerShell Version 5

PowerShell Version 6

PowerShell Version 6

To enable version 6 in a custom profile, you first need to download and install PowerShell Core 6. After that you can make the following change to the command like key:

"commandline" : "pwsh.exe",

I also added the PowerShell Core 6 Avatar to my background image. If you would like the add the image it can be found here. I also had to convert the SVG to a PNG. You can do that here.

Emoji in Scripts

Finally, there is the concept the VSCode and PowerShell Core 6/The New Windows Terminal understand Unicode characters. What does that mean to us? EMOJIS IN SCRIPTS 😁😂😜!!!!

A straightforward example of this is to show the write-host Cmdlet in VSCode. First, we form our write-host then wherever we want to insert an emoji, we press “WIN-.” On the keyboard. That’s the Windows key and the period. From that menu, we can insert our emoji into our PowerShell script.

Emojis in Script

Once we save and run the script in the New Terminal, this is what we see:

New Terminal Script

In Closing

I hope this post has helped you to understand the customization options available in the new Windows Terminal. In the future, I’m sure the customization options will receive better documentation or maybe a UI configure them.

Now get to downloading, and I hope you have as much fun making the new terminal your own!

Microsoft has over a thousand Virtual Machine images available in the Microsoft Azure Marketplace. If your organization has their own on-premises “Gold Image” that’s been tailored, hardened, and adapted to meet specific organizational requirements (compliance, business, security, etc.), you can bring those images into your Azure subscription for reuse, automation, and/or manageability.

I recently had the opportunity to take a client’s virtualized Windows Server 2008 R2 “Gold Image” in .OVA format (VMware ), extract the contents using 7-Zip, run the Microsoft Virtual Machine Converter to create a VHD, prepare and upload the VHD, and create a Managed Image that was then deployed using PowerShell and an Azure Resource Manager Template.

It’s actually quite simple! Here’s how… Read More…

(Part One of this series can be found here.)

Deploying Azure ARM Templates with PowerShell

After you’ve created your template, you can use PowerShell to kick off the deployment process. PowerShell is a great tool with a ton of features to help automate Azure processes. In order to deploy Azure ARM Templates with PowerShell, you will need to install the Azure PowerShell cmdlets. You can do this by simply running the command Install-Module AzureRM inside a PowerShell session.

Check out this link for more information on installing Azure PowerShell cmdlets. PowerShell works best on a Windows platform, although there is a version now out for Mac that you can check out here. You can also use Azure CLI to do the same thing. PowerShell and Azure CLI are quick and easy ways to create resources without using the Portal. I still stick with PowerShell, even though I primarily use a Mac computer for development work. (I’ll talk more about this in the next section.) Read More…

At AIS, our Account Teams work with our clients every day to produce IT solutions that solve business problems. We work closely with our CTO organization to ensure that we are researching the latest technology and services in a manner that is applicable to our clients and prospective clients.

We recently applied this to a business problem that required an organization to quickly — and with no notice — stand up a website to collect hundreds, or potentially millions, of submissions from the general public.  Our use case focused on law enforcement and the sorts of emergency response situations we’ve seen all too often in the news, such as the Boston Marathon bombing.  When local, state or federal authorities respond to criminal acts, they seek to quickly collect vast amounts of input from the public.  This input can be in the form of tips, photos, videos or any untold number of observations.  Agencies need the capability to surge their IT tools and applications to collect the data, store it, and run analysis tools against the collected content to harvest information. Read More…

I recently needed to make several web.config changes to our production SharePoint 2010 web farm. Making all of these modifications manually would have been tedious and would have left a lot of room for error. After doing some research to find a better way, I discovered the SPWebConfigModification class in the Microsoft.SharePoint.Administration namespace.

This is basically  a collection of changes to be made to web.config files that can be stored and then applied to all web front-end servers in a farm. This class is available with SharePoint 2010 and 2013. Unfortunately, the class is poorly documented so I had some trouble figuring out how to use it. You could write a console application to use the SPWebConfigModification class or you could use a feature receiver, but I found that the easiest approach was to just use it with PowerShell. After some trial and error, I came up with the following four PowerShell scripts that can be reused to read, add, remove, and completely clear the SPWebConfigModifications on the server. Read More…

An Enterprise Service Bus (ESB) is a shared messaging layer that gives you a consistent, scalable and flexible means of coordinating across disparate, loosely-connected services to execute business processes. Over the years, Microsoft has developed several service bus technologies:

BizTalk: A messaging and workflow orchestration platform to build ESB behaviors and capabilities. The BizTalk ESB toolkit provides a set of guidelines, patterns and tools.

Windows Azure Service Bus (ASB): This provides the messaging infrastructure for applications that live in the cloud, in your data center, and crosses all devices and PCs.

Service Bus for Windows Server (SBWS):  SBWS is based on ASB and shares many of the same capabilities, such as queue, topic and subscription support.  A distinct design goal is to ensure symmetry between SBWS and ASB and allow for a single set of code to be leveraged across both deployment environments.

Read More…

Have you ever wanted a fresh SharePoint development environment? Have you ever needed to quickly create a test box, or wanted to prototype something specifically for a customer? In the past, in all of these scenarios, you’d face a very time-consuming process and quite honestly, one that has likely been a deterrent. In this blog post, I’m going to walk you through creating a SharePoint 2013 development environment, on Azure, utilizing the Visual Studio 2013 RC.

Thanks to the good people at Microsoft, there is now a developer image on Azure that comes with SharePoint 2013 and Visual Studio 2013 Ultimate RC, already installed. Before we get too far along, I do have to warn you that you’ll need either an Azure or MSDN subscription. If you don’t have an Azure subscription, you can activate your MSDN Azure benefit and receive up to $150 USD in free, monthly Azure credits. If you are careful to shut down your VM at the end of each work day, then you should be able to use this VM as your day-to-day development machine without eating up all of your credits. Read More…