IIS (.NET) Deployment

Updated 2 months ago by Michael Cretzman

Harness provides support for Microsoft IIS and .NET for Azure and AWS deployments. Your Harness applications support IIS in the following entities:

  • Services: There are three IIS service types:
    • IIS Website.
    • IIS Application.
    • IIS Virtual Directory.
    • For all service types, Harness automatically creates the Deployment Specification, which you can customize.
  • Environments: You can deploy your services to Windows instances in your enterprise network or VPC, such as AWS and Azure.
  • Workflows: Harness provides Basic, Canary, Blue/Green, Multi-Phase, and Rolling Deployment options. Default Rollback, Notification, and Failure Strategies are provided and can be easily changed.
  • Pipelines and Triggers: Create pipelines containing multiple workflows and triggers to run your workflows or pipelines automatically.

Harness provides PowerShell and WinRM support to execute workflows and communicate within the Microsoft ecosystem.

It is important to note that a site contains one or more applications, an application contains one or more virtual directories, and a virtual directory maps to a physical directory on a computer. To use Harness to deploy IIS sites, applications, and virtual directories, the IIS structural requirements (site > application > virtual directory) must be established on the Windows instances.

Before deploying the IIS website, application, or virtual directory to your Windows instances, there must be an existing IIS Web Server Role on the instance. This ensures that the environment is ready for deployment. Harness IIS Website deployment requires the IIS Web Server Role. The Harness IIS Application and IIS Virtual Directory deployments require that an IIS Website exists. For more information, see Installing IIS from the Command Line below.

For information about IIS sites, applications, and virtual directories, see Understanding Sites, Applications, and Virtual Directories on IIS 7.

Deployment Overview

Deploying IIS websites, applications, or virtual directories using Harness is a simple process. It involves setting up your deployment environment, establishing a connection with Harness, and then using Harness to define your deployment goals.

Here are the major steps in an IIS (.NET) deployment:

  1. Add connections:
    1. WinRM Connection: Add a WinRM connection in Harness to execute deployment steps on the remote Windows servers. The connection must use a user account with permission to execute commands on the Windows instances.
    2. Cloud Provider: Add a connection to the Cloud Provider where the IIS website, application, or virtual directory will be deployed, such as AWS or Azure.
    3. Artifact Server: Add a connection to the Artifact Server where Harness can pull the IIS website, application, or virtual directory artifacts.
  2. Application: Add a Harness application for your IIS website, application, or virtual directory. An application is a logical grouping of entities, such as services, environments, workflows, and triggers.
  3. Service: Add a service in your application for each IIS website, application, or virtual directory. This guide covers IIS Website, IIS Application, and IIS Virtual Directory.
  4. Environment: Add an environment and a service infrastructure that consists of a WinRM Deployment type and a cloud provider connection that specifies the deployment VPC, subnets, security groups, etc. Or, if the environment is a physical data center, specify the IP address.
  5. Workflow: Add a workflow to deploy your website, application, or virtual directory. Will we review the workflow steps generated by Harness automatically.
  6. Deploy: Deploy your workflow, observe the deployment steps in real-time, and confirm in your VPC.
  7. Continuous Verification: Once your deployments are successful, you can add verification steps into the workflow using your verification provider. For more information, see Continuous Verification.
  8. Refinements: Add notification steps, failure strategy, and make your workflow a template for other users. For more information, see Add a Workflow.

Before You Begin

This guide assumes that you are familiar with Harness architecture and have downloaded the Harness delegate into your enterprise network or VPC. For more information, see:

Set Up Connections

The following procedure sets up the WinRM Connection, Artifact Server, and Cloud Provider for your IIS Deployment. You can use these connections globally for all the IIS services and environments you add in Harness, or restrict them to specific applications and environments.

To set up your connections, do the procedures in the following sections.

Harness Delegate Connections for Azure

A Harness delegate needs to connect to the artifact servers, cloud providers, and hosts you configure with Harness. The delegate is only supported for Linux and cannot be run on a Windows VM in Azure.

To ensure that the harness delegate you use for Azure deployments can connect to your Azure resources, you can run the delegate on a Linux VM in your Azure VPC (such as Ubuntu) or simply ensure that the delegate has network access to resources in your Azure VPC.

Set Up WinRM on Instances and Network

WinRM is a management protocol used by Windows to remotely communicate with another server, in our case, the Harness delegate. WinRM communicates over HTTP (5895)/HTTPS (5896), and is included in all recent Windows operating systems.

For WinRM, you need the following networking configured:

  • The VMs must listen on HTTP (5895)/HTTPS (5896)
  • Open the VMs ports for HTTP (5895)/HTTPS (5896)
  • Open the subnet ports for HTTP (5895)/HTTPS (5896)

In cases where WinRM is not already set up on your Windows instances, you can set it up using the following command:

Invoke-Expression ((New-Object System.Net.Webclient).DownloadString('https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1')) 
We recommend using this command as it configures the necessary port and firewall settings for the Windows instance.
Set Up WinRM in Azure

Here is an example of the PowerShell set up of WinRM on an Azure Windows Server VM.

C:\Users\harness>PowerShell.exe
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:\Users\harness> Invoke-Expression ((New-Object System.Net.Webclient).DownloadString('https://raw.githubusercontent.
com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1'))
Self-signed SSL certificate generated; thumbprint: 4B4AAFE402B3B96EAC3C26FE0DE7332E9010B1C7


wxf : http://schemas.xmlsoap.org/ws/2004/09/transfer
a : http://schemas.xmlsoap.org/ws/2004/08/addressing
w : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
lang : en-US
Address : http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
ReferenceParameters : ReferenceParameters

Ok.

PS C:\Users\harness> exit

C:\Users\harness>winrm e winrm/config/listener
Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.0.1.4, 127.0.0.1, ::1, 2001:0:9d38:90d7:1868:10ad:f5ff:fefb, fe80::5efe:10.0.1.4%9, fe80::1868:10ad:f5ff:fefb%10, fe80::915e:d4bb:bf06:9807%5

Listener
Address = *
Transport = HTTPS
Port = 5986
Hostname = doc
Enabled = true
URLPrefix = wsman
CertificateThumbprint = 4B4AAFE402B3B96EAC3C26FE0DE7332E9010B1C7
ListeningOn = 10.0.1.4, 127.0.0.1, ::1, 2001:0:9d38:90d7:1868:10ad:f5ff:fefb, fe80::5efe:10.0.1.4%9, fe80::1868:10ad:f5ff:fefb%10, fe80::915e:d4bb:bf06:9807%5

You can also see WinRM running in Server Manager:

You can also test if the WinRM service is running on a local or remote computer using the Test-WSMan PowerShell command. For more information, see Test-WSMan from Microsoft.

Ensure that the ports you need for the WinRM connection are open on your network security group and VM. For more information, see How to open ports to a virtual machine with the Azure portal to open the WinRM Inbound security rule.

Network Security Group:

VM Inbound Port Rules:

For more information about Azure and WinRM, see the following:

Set Up WinRM in AWS

In AWS EC2, you can enter the command as User data when creating the instance:

<powershell>
Invoke-Expression ((New-Object System.Net.Webclient).DownloadString('https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1'))
</powershell>

If you launch more than one instance at a time, the user data is available to all the instances in that reservation.

You can also remote into the EC2 instance, open a PowerShell session, and run the Invoke-Expression.

To verify that WinRM is running on your Windows instance, run the command:

winrm e winrm/config/listener

The successful output will be something like this:

C:\Windows\system32&gt;winrm e winrm/config/listener
Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 127.0.0.1, ....

Listener
Address = *
Transport = HTTPS
Port = 5986
Hostname = EC2AMAZ-Q0MO0AP
Enabled = true
URLPrefix = wsman
CertificateThumbprint = 1A1A1A1A1A1A1A1A1A1A1
ListeningOn = 127.0.0.1, ...

For more information about EC2 and WinRM, see the following:

If the default methods for setting up WinRM in your Windows instances is not working, try the script listed here: Configure a Windows host for remote management with Ansible.

Set Up the WinRM Connection in Harness

Add a WinRM connection in Harness to execute deployment steps on the remote Windows servers.

  1. Mouseover Continuous Security, and then click Secrets Management. The Secrets Management page appears.
  2. Under Executions Credentials, click WinRM Connection. The WinRM Connection Attributes dialog appears.
  3. Fill out the WinRM Connection Attributes dialog and click SUBMIT. The WinRM Connection Attributes dialog has the following fields.

Field

Description

Name

Name to identify the connection. You will use this name to identify this connection when setting up the Connection Attributes in the environment Service Infrastructure.

Auth Scheme

Specifies the mechanism used to authenticate the credentials used in this connection. Currently only NTLM is supported.

Domain

The Active Directory domain name where the user account in the credentials is registered. This can be left blank when using a local user.

User Name / Password

The user account credentials for this connection. The user must belong to the same Active Directory domain as the Windows instances that this connection uses. These are the same user account credentials you would use to log into the VM using a remote connection such as Microsoft Remote Desktop.

Use SSL

Enables an HTTPS connection instead of an HTTP connection. SSL is recommended.

Skip Cert Check

When connected over HTTPS (Use SSL in enabled), the client does not validate server certificate.

WinRM Port

Specifies the network port on the remote computer to use.

To connect to a remote computer, the remote computer must be listening on the port that the connection uses. The default ports are 5985, which is the WinRM port for HTTP, and 5986, which is the WinRM port for HTTPS.

To determine what ports WinRM is listening on, use the command:

winrm e winrm/config/listener

Cloud Provider Connection

Add a connection to the Cloud Provider where the IIS website, application, or virtual directory will be deployed.

  1. Click Setup, and then click Cloud Providers. The Cloud Providers page appears.
  2. Click Add Cloud Provider. The Cloud Provider dialog appears.
  3. In Type, select the type of cloud provider you want to add, such as Amazon Web Services or Microsoft Azure. The dialog settings will change for each cloud provider.
  4. Enter the cloud provider account information, and then click SUBMIT. For account details and Harness permission requirements for the different providers, see Add Cloud Providers (AWS, Azure).
    Once you have created Harness applications and environments, you can return to this dialog and add Usage Scope on which applications and environments may use this provider.
For certain Cloud Providers, such as AWS, instead of using account information to set up the Cloud Provider, you can install a Harness Delegate in your VPC and use its credentials for your Cloud Provider. After you install the Delegate, you add a Tag to the Delegate, and then simply select that Tag in the Cloud Provider dialog. For an example, see Installation Example: Amazon Web Services and ECS.

Artifact Server Connection

Add a connection to the Artifact Server where Harness can pull the IIS website, application, or virtual directory artifact.

If you are using the same Cloud Provider as artifact server, then you can skip this step. For example, if you added AWS EC2 as a Cloud Provider and you are using AWS S3 as an artifact server, you do not need to add AWS S3 as an artifact server. You can simply use the same AWS connection.
  1. Click Setup, and then click Connectors. The Connectors page appears.
  2. Click Artifact Server, and then click Add Artifact Server. The artifact server dialog appears.
  3. In Type, click the artifact source you want to use. The dialog settings will change for each server.
  4. Enter the artifact server information and click SUBMIT. For account details and Harness permission requirements for the different servers, such as SMB and SFTP, see Add Artifact Servers.
    Once you have created Harness applications and environments, you can return to this dialog and add Usage Scope on which applications and environments may use this server.

Now that you have connected the IIS artifact server and a cloud provider, and configured a WinRM connection to execute deployment steps on the remote Windows servers, you can add your Harness application.

Azure Storage is not currently supported as an Artifact Source. Azure Container Registry is supported for Docker and Kubernetes deployments.

IIS Deployment Overview

The following procedures pull IIS website, application, and virtual directory metadata from AWS S3 and deploy them to a Windows instance in AWS EC2 or a Microsoft Azure VM. Both deployment environments are explained. To deploy an IIS website, application, and virtual directory, follow the procedures below.

Add Harness Application

A Harness application is a logical grouping of the services, environments, and workflows for your IIS website deployment.

To add the IIS application, do the following:

  1. Click Setup, and then click Add Application. The Application dialog appears.
  2. Enter the name for your application, such as IIS-Example, and click SUBMIT. Your new application appears.
  3. Click your application’s name. The application entities appear. These are the tools you will use to define and execute your deployment.

Add IIS Website Service

Services include artifact sources, deployment specifications, and configuration variables. For more information, see Add a Service.

In this procedure you will define which artifact(s) to use for your IIS Website. Harness will then create a Deployment Specification using PowerShell.

To add a service for your IIS Website, do the following:

  1. In your application, Click Services, and then click Add Server. The Service dialog appears.
  2. Give the service a name, such as IIS-website.
  3. In Artifact Type, select IIS Website.
  4. Click SUBMIT. The service is displayed. In Service Overview you can see the name and type of your service.
  5. To add the artifact source for your IIS website, click Add Artifact Source. A list of artifact source types appears.
  6. Click the artifact source type. The artifact sources consist of the cloud providers and build servers you added earlier. For this guide, we will use Amazon S3. Harness also supports other popular Windows protocols such as SMB and SFTP.
  7. For the Amazon S3 example, in Cloud Provider, select the S3 provider you added earlier. Harness connects to the provider automatically
  8. In Bucket, select one of the buckets in the S3. The list is automatically populated by Harness.
  9. In Artifact Path, select the file(s) for your IIS website. The list is automatically populated by Harness. For this guide, we will use a zip file.
    For WinRM connections, Harness does not use direct artifact copy when you set up the Service. Metadata is supported and is used to download the artifact directly on to the Windows Host during deployment runtime. For this reason, ensure that the target host has connectivity to the Artifact Server before deploying.
    When you are finished, the Artifact Source will look something like this:
  10. Click SUBMIT. Harness builds the service, including the Deployment Specification.


    The Deployment Specification section is automatically filled the Install IIS Website template, which pulls the artifact, expands it, creates the Application Pool (AppPool) and creates the website. Later you will create the environment where the scripts will be executed.
    To add more scripts, mouseover anywhere in the script and click the plus icon:

By default the Install IIS Website Template is linked to the template in the Template Library and its scripts cannot be edited in the Service (although its variables may be edited). To modify its scripts, you must copy the template instead of linking to it. To do this, in the Deployment Specification, click Add Command, select From Template Library, select the Install IIS Website Template, and choose Copy instead of Link.

The template is copied to the Service and you can modify its scripts.

Install IIS Website Template

When you create a Service of type IIS Website, a link to the Install IIS Website template is added to the Service. The template contains the following script steps:

  • Download Artifacts - As noted earlier, for WinRM connections, Harness does not use direct artifact copy when you set up the Service. Meta-data is supported and is used to download the artifact directly on to the Windows Host during deployment runtime. Ensure the target host has connectivity to your Artifact Server.
  • Expand Artifacts - PowerShell script runs to expand the artifact.
  • Create App Pool - See Application Pools below.
  • Create Website - PowerShell script to create the IIS Website.

For more information on templates, see Use Templates.

Template Variables

To edit the variables used in the Install IIS Website Template in the Service, click Variables. The Edit Command dialog appears.

Add values for the variables as needed. The variables used in the Install IIS Website Template in the Service can be modified without influencing the Install IIS Website Template in the Template Library.

Application Pools

Harness manages the deployment of the new IIS website, application, or virtual directory artifacts to your Windows instances using the default Application pool. If you want to specify the Application pool, use the applicationPool element, adding it to the New-Item script during application creation.

For more information, see:

When you create the IIS services in Harness, you can modify the AppPool name used in the Create AppPool settings of the Deployment Specification.

Add IIS Application Service

In this procedure you will define which artifact(s) to use for your IIS Application. Harness will then create a Deployment Specification using PowerShell.

To add a service for your IIS Application, do the following:

  1. In your application, Click Services, and then click Add Server. The Service dialog appears.
  2. Give the service a name, such as IIS-application.
  3. In Artifact Type, select IIS Application.
  4. Click SUBMIT. The service is displayed.



    In Service Overview you can see the name and type of your service.
  5. To add the artifact source for your IIS application, click Add Artifact Source. A list of artifact source types appears.
  6. Click the artifact source type. The artifact sources consist of the cloud providers and build servers you added earlier. For this guide, we will use Amazon S3.
  7. For the Amazon S3 example, in Cloud Provider, select the S3 provider you added earlier. Harness connects to the provider automatically
  8. In Bucket, select one of the buckets in the S3. The list is automatically populated by Harness.
  9. In Artifact Path, select the file(s) for your IIS application. The list is automatically populated by Harness. For this guide, we will use a zip file.
    For WinRM connections, Harness does not use direct artifact copy when you set up the Service. Metadata is supported and is used to download the artifact directly on to the Windows Host during deployment runtime. For this reason, ensure that the target host has connectivity to the Artifact Server before deploying.
    When you are finished, the Artifact Source will look something like this:

Click SUBMIT to add the artifact source. Harness builds the service, including the Deployment Specification.

The Deployment Specification section is automatically filled with, and linked to, the Install IIS Application template.

By default, the Install IIS Application template is linked to the template in the Template Library and its scripts cannot be edited in the Service (although its variables may be edited). To modify its scripts, you must copy the template instead of linking to it. To do this, in the Deployment Specification, click Add Command, select From Template Library, select the Install IIS Application Template, and choose Copy instead of Link.

Install IIS Application Template

When you create a Service of type IIS Application, a link to the Install IIS Application template is added to the Service. The template contains the following script steps:

  • Download Artifact - As noted earlier, for WinRM connections, Harness does not use direct artifact copy when you set up the Service. Meta-data is supported and is used to download the artifact directly on to the Windows Host during deployment runtime. Ensure the target host has connectivity to your Artifact Server.
  • Expand Artifacts - PowerShell script runs to expand the artifact.
  • Create Virtual Directory - PowerShell script runs to create the Virtual Directory.

For more information on templates, see Use Templates.

To edit the values for variables used in the template, click Variables. The variables used in the Install IIS Application template in the Service can be modified without influencing the Install IIS Application Template in the Template Library.

Add IIS Virtual Directory Service

In this procedure you will define which artifact(s) to use for your IIS virtual directory. Harness will then create a Deployment Specification using PowerShell.

To add a service for your IIS virtual directory, do the following:

  1. In your application, Click Services, and then click Add Server. The Service dialog appears.
  2. Give the service a name, such as IIS-virtual-directory.
  3. In Artifact Type, select IIS Virtual Directory.
  4. Click SUBMIT. The service is displayed. In Service Overview you can see the name and type of your service.
  5. To add the artifact source for your IIS virtual directory, click Add Artifact Source. A list of artifact source types appears.
  6. Click the artifact source type. The artifact sources consist of the cloud providers and build servers you added earlier. For this guide, we will use Amazon S3.
  7. For the Amazon S3 example, in Cloud Provider, select the S3 provider you added earlier. Harness connects to the provider automatically
  8. In Bucket, select one of the buckets in the S3. The list is automatically populated by Harness.
  9. In Artifact Path, select the file(s) for your IIS virtual directory. The list is automatically populated by Harness. For this guide, we will use a zip file.
    For WinRM connections, Harness does not use direct artifact copy when you set up the Service. Meta-data is supported and is used to download the artifact directly on to the Windows Host during deployment runtime. For this reason, ensure that the target host has connectivity to the Artifact Server before deploying.
    When you are finished, the Artifact Source will look something like this:

Click SUBMIT to add the artifact source. Harness builds the service, including the Deployment Specification.

The Install IIS Application template is also used for the IIS Virtual Directory service type. By default, as with the IIS Application Service, the Install IIS Application template is linked to the template in the Template Library and its scripts cannot be edited in the Service (although its variables may be edited). To modify its scripts, you must copy the template instead of linking to it. To do this, in the Deployment Specification, click Add Command, select From Template Library, select the Install IIS Application Template, and choose Copy instead of Link.

You can modify the variables of the Install IIS Application template scripts by click Variables. The variables used in the Install IIS Application template in the Service can be modified without influencing the Install IIS Application Template in the Template Library.

Click Create Virtual Directory, and the Create Virtual Directory dialog appears. The dialog contains the following default PowerShell script that will be run during shell session of your Harness workflow:

Import-Module WebAdministration

$siteName="Default Web Site"
$releaseId="${workflow.ReleaseNo}"
$virtualDirectoryName="${service.Name}"
$appPhysicalDirectory=$env:SYSTEMDRIVE + "\Artifacts\" + $virtualDirectoryName + "\release-" + $releaseId

Write-Host "Creating Virtual Directory" $virtualDirectoryName ".."
$VirtualDirPath = 'IIS:\Sites\' + $siteName + '\' + $virtualDirectoryName
New-Item -Path $VirtualDirPath -Type VirtualDirectory -PhysicalPath $appPhysicalDirectory -Force

Write-Host "Done."

Note the following:

  • The $releaseId variable has the value ${workflow.ReleaseNo}. This is one of the builtin Harness variables. For more information, see Variables and Expressions in Harness.
  • The $VirtualDirPath variable shows you where your IIS directory will be deployed.

When you deploy this service as part of your workflow, you will see these variables used in the Harness deployment dashboard:

Add IIS Deployment Environment in AWS or Azure

Add an Environment, a Service Infrastructure that consists of a WinRM Deployment type, and a Cloud Provider connection that specifies the deployment VPC. For more information, see Add an Environment.

To add an environment for your IIS Website, do the following:

  1. In your application, click Environments. The Environments page for the applications appears.
  2. Click Add Environment. The Environment dialog appears.
  3. Enter a name for your deployment environment, such as IIS-EC2, and then, in Environment Type, click Non-Production or Production. When you are finished, click SUBMIT. The Environment page appears.




    Next, you will add a Service Infrastructure, using the Cloud Provider you added to define where your IIS Website will be deployed.
  4. Click Add Service Infrastructure. The Service Infrastructure dialog appears.

  5. Fill out the Service Infrastructure dialog using the following information.

AWS Service Infrastructure

This following table describes the fields for an AWS EC2 service infrastructure.

Field

What to Enter

Service

Select the service you created for your IIS Website.

Deployment Type

Select Windows Remote Management (WinRM).

Cloud Provider

Select the Cloud Provider you added.

Provision Type

If you have a Windows instance running in your Cloud Provider, click Already Provisioned. If you need to set up an instance, create the instance in your Cloud Provider, and then return to the Harness environment set up.

If you have an Infrastructure Provisioner configured, select Dynamically Provisioned. This guide does not cover Harness Infrastructure Provisioners. For more information, see Add an Infra Provisioner.

Region

Region for the VPC.

Load Balancer

The load balancer used by the VPC.

WinRM Connection Attributes

Select the name of the WinRM Connection you created. This is the value you entered in Name when you created the WinRM Connection in Secrets Management.

Host Name Convention

Host Name Convention is used to derive the instance(s) hostname. The hostname that results from the convention should be same as the output of the command hostname on the host itself. Agent-based solutions like AppDynamics, Splunk, New Relic, etc, use the hostname to uniquely identify the instance.

In most cases, you can leave the default expression in this field.

For information on obtaining the AWS instance hostname, see Instance Metadata and User Data from AWS.

User Auto Scaling Group / Use AWS Instance Filter

User Auto Scaling Group: If you are using an Auto Scaling Group, you can select it from the list.

Use AWS Instance Filter: Specify the VPC, Tags, Subnet, and Security Group where your instance(s) will be deployed.

Using Tags is the easiest way to reference an instance.

Use Public DNS for connection

If locating the VPC requires public DNS name resolution, enable this option.

When you are finished, the Service Infrastructure dialog will look something like this:

Click SUBMIT. The new service infrastructure is listed.

Azure Service Infrastructure

You can locate most of the Azure information on the VM overview page:

This following table describes the fields for an Azure service infrastructure.

Field

What to Enter

Service

Select the service you created for your IIS Website.

Deployment Type

Select Windows Remote Management (WinRM).

Cloud Provider

Select the Cloud Provider you added.

Subscription ID

Select the Azure subscription to use.

When you set up the Azure cloud provider in Harness, you entered the Client/Application ID for the Azure App registration. To access resources in your Azure subscription, you must assign the Azure app using this Client ID to a role in that subscription. Now, when you are setting up an Azure service infrastructure in a Harness environment, you select the subscription. If the Azure App registration using this Client ID is not assigned a role in a subscription, no subscriptions will be available.

For more information, see Assign the application to a role from Microsoft.

Resource Group

Select the resource group where your VM is located.

WinRM Connection Attributes

Select the name of the WinRM Connection you created. This is the value you entered in Name when you created the WinRM Connection in Secrets Management.

Tags

Click Add to use a tag to quickly select the VM you want to use.

Use Public DNS for connection

If locating the VM(s) requires public DNS name resolution, enable this option. Since the Harness delegate can only run on Linux, it must either be run on a Linux VM in the same subnet as your deployment target VMs or on a Linux server with network access to your Azure VMs. In the latter case, you can use public DNS to resolve the hostname of the target VMs.

When you are finished, the Service Infrastructure dialog will look something like this:

Click SUBMIT. The new service infrastructure is listed.

Add IIS Workflows

Next, add a workflow to deploy your website. Will we review the workflow steps generated by Harness automatically.

You can create workflows for your IIS application and IIS virtual directory services using the same steps as below.

Workflows are the deployment steps for services and environments, including types such as Canary and Blue/Green. Workflows also include verification, rollback, and notification steps.

  1. In your application, click Workflows.
  2. Click Add Workflow. The Workflow dialog appears.



    The dialog has the following fields.

    Field

    Description

    Name

    Give your workflow a name and description that tells users its purpose.

    Workflow Type

    In this guide, we will do a simple Basic workflow. For a summary of workflow types, see Add a Workflow.

    Environment

    Select the environment you added.

    Service

    Select your IIS Website service.

    Service Infrastructure

    Select the service infrastructure you added.

    When you are finished, click SUBMIT. The workflow is generated:

  3. Under Prepare Infra, click Select Nodes. The Node Select dialog appears.



    If you deploy in multiple phases, you can control what hosts to use for each phase. If you are simply doing one phase, you do not need to select hosts.

    The Node Select dialog has the following fields.

    Field

    Description

    Select Specific hosts?

    Select Yes to enter the hostname(s) of the nodes where you want the website deployed.

    Select No to have Harness select the host(s) in the service infrastructure based on how set up the service infrastructure in Environment.

    Instances

    Enter the number of instances you want deployed.

    Instance Unit Type

    Identify if the number in Instances is a count or percentage. For example, if you select 10 in Instances, you can select Count and the artifact is deployed to 10 instances. Or you can enter 100 in Instances and select Percent and the artifact is deployed to 100% of the instances in the service infrastructure.

    When you finished, click SUBMIT.
  4. Under Deploy Service, click Install. The Install dialog appears.



    You can set how long the installation may take before it's timed out. The default is 60000ms or 10 minutes. When you are finished, click SUBMIT.

Now that your workflow is complete, you are ready to deploy.

Deploy IIS Website

Now you can deploy your workflow, observe the deployment steps in real-time, and confirm in your VPC.

  1. In your workflow, click Deploy.


    The Start New Deployment dialog appears.



    Here you simply select the artifact build and version to be deployed.
  2. In Artifacts, click the dropdown menu and select the artifact build and version to deploy. The list is generated automatically by Harness from the artifact source you specified when you set up your service.

    You can also elect to skip any instances that already have the artifact build and version.
  3. Click SUBMIT to deploy. Harness shows the deployment in real-time:

Each workflow step is displayed. Click through each deployment step to see the logs and details.

Confirm Deployment in your Windows Instance

Now that the deployment was successful, confirm the website was added to the Windows instance(s):

  1. In your workflow Deployment page, click the Install step.
  2. Expand the Create Website section.
  3. In the log, note the location where the website was created:

    INFO 2018-08-27 15:34:43 IIS-website 2 Started C:\Artifacts\IIS-website\relea http :8080:*
  4. Connect to your Windows instance via Microsoft Remote Desktop or other console.
  5. On the Windows instance, navigate to the location Harness reported to confirm the website was created:

Deploy IIS Pipeline

Once you have workflows for your IIS website, application, and virtual directory set up, you can create a Harness pipeline that deploys them in the correct order. For IIS, you must deploy them in the order website, application, and then virtual directory.

In you Harness application, click Pipelines. Follow the steps in Add a Pipeline to add a stage for each of your workflows.

When you are done, the pipeline will look like this:

Click Deploy. The Start New Deployment dialog opens. Select each workflow artifact. When you are done, the dialog will look like this:

Click SUBMIT. Here's what the pipeline looks in the deployment dashboard. You can see each Stage was successful:

Next Steps

Now that you have a working deployment, you can use the Harness Continuous Verification machine learning to verify and improve your deployments. For more information, see Continuous Verification.

Enhance your ISS deployment workflow(s) with the multiple options available, including Failure Strategy, Rollback Steps, Barriers, and templating. For more information, see Add a Workflow.

Best Practices

Testing Scripts

When modifying the default scripts, it is better to test test your scripts on a Windows instance using PowerShell_ise than deploying your workflow multiple times.

Using Tags for Instances

When configuring the Service Infrastructure in Environment, instance Tags make identifying your instances easier. Assign the same tag to all instances and simply use that tag.

Installing IIS from the Command Line

Before deploying the IIS website, application, or virtual directory to your Windows instances, there must be at least an existing IIS Web Server Role on the instance.

The following script will prepare your Windows instance with the necessary IIS set up:

Start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security;IIS-RequestFiltering;IIS-HttpCompressionStatic;IIS-WebServerManagementTools;IIS-ManagementConsole;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

You will see IIS installed in the Server Manager.

In the IIS listing, in ROLES and FEATURES, you can see the Web Server Role:

For more information, see Installing IIS 7.0 from the Command Line from Microsoft.

Troubleshooting

The following problems can occur when deploying your IIS website, application, or virtual directory.

Error: No delegates could reach the resource

You receive this error when deploying your workflow.

Solutions
  • Ensure your artifact can be deployed via WinRM onto a Windows instance. It's possible to select the wrong artifact in Service.
  • Ensure you have access to the deployment environment, such as VPC, subnet, etc.
  • Ensure your WinRM Connection can connect to your instances, and that your instances have the correct ports open. See Set Up WinRM on Your Instances above.

Port Conflicts

Do not target the same port as another website. In service, in Create Website, ensure $SitePort=80 points to a port that isn't in use. In the following example, the port was changed to 8080 to avoid the error:

You can keep the same port and use host header names to host multiple IIS sites using the same port. For more information, see How To Use Host Header Names to Configure Multiple Web Sites in Internet Information Services 5.0. This article is about an old version of IIS, but the same concepts apply.


How did we do?