DevOps Set Default Azure Subscription with Azure CLI

DevOps for Azure configuration and deployment is a key component of cloud operations management without having the need to use the Azure user interface. When there are multiple subscriptions to manage, we need to make sure that we first select the correct subscription from Azure. We can take a look at how this can be done using Azure CLI 2.0  (install from this site).

CodeProject

After opening the Bash command shell, follow these steps:

Login to Azure

We can login to our Azure account using the login command. This requires some browser interaction to enter a code for the two factor authentication.

az login

List Our Subscriptions

After a successful login, we can list all of our current subscription using the account command.

az account –list –all –output table

We can see the returning JSON with a list of accounts that are available in a nice table format.  Each reference has a name and isDefault property. Only one of them is our default subscription.

Set a Default Subscription

We can change our default subscription by running the account set command.

az account set  --subscription “my subscription name”

Validate Default Subscription

We should be able to list all the subscriptions again and verify that the default subscription is correct by filtering the results using GREP. (Note this work when using Bash)

az account –list –all –output table | grep “True”

The result should be only the subscription that is set to IsDefault = true.

At this point, we should be on the right subscription, and we can move forward with any additional configuration using Azure CLI.

Originally published by ozkary.com

Input Range Slider with Color Indicator

The HTML input type range lets us specify a numeric value which falls within a min and max value. For some use cases, we want to style the control in such a way that provides a visual feedback that is related to the selected value.  In our example, we can create a slider control that maps to three different system statuses:

Status	Control Value	Background Color
Down	1	Red
Idle	2	Gray
Running	3	Green

We want to be able to change the background color of the thumb control to match the slider value. In order to do this, we first need to create the base CSS classes to style the control. We are also creating some thumb classes with the corresponding background color.

.slidecontainer {         width: 100%;     }     .slider {         -webkit-appearance: none;         width: 100%;         height: 30px;         border-radius: 5px;         background: #d3d3d3;         outline: none;         opacity: 0.7;         -webkit-transition: .2s;         transition: opacity .2s;     }         .slider:hover {             opacity: 1;         }         .slider::-webkit-slider-thumb {             -webkit-appearance: none;             appearance: none;             width: 50px;             height: 50px;             border-radius: 50%;             background: gray;             cursor: pointer;         }     .thumb1::-webkit-slider-thumb {         background: red;     }     .thumb2::-webkit-slider-thumb {         background: gray;     }     .thumb3::-webkit-slider-thumb {         background: green;     }

Now that we have styled our control, we want to map the selected slider value to a CSS class that we defined. We can do this by using the range control oninput event which fires when the value changes.

var slider = document.getElementById("myRange");     var output = document.getElementById("demo"); CodeProject     var thumb = {"1":"thumb1","2":"thumb2","3":"thumb3"};     output.innerHTML = thumb[slider.value];     slider.oninput = function() {       output.innerHTML =thumb[this.value];       slider.className = 'slider ' + thumb[this.value];     }

In the code, we define a hash table with the possible slider values as keys. This enables us to quickly resolve the class name for the current value. When the value changes, we set the range controller class name to the slider base class plus the thumb class which provides the button background color.

With this article, we are able to show how easy it is to style the range input control to make it provide better visual feedback to the end users.

Originally published by ozkary.com

SharePoint 2013 Move Documents to Another Library Using Content Organizer Web Service

A common task for document management system is to move a document from one library to another based on a particular condition or content type. To enable this feature, SharePoint provides some core actions that can let you copy the document to another site collection and then delete it from the source. 

CodeProject

In our case, we want to be able to move the document using a more complex action called Send Document to Repository which moves a document by using the Content Organizer Web Service.

Note:  Content type enables us to organize documents and associate them to content rules which can enable us to route documents to specific document libraries.

Configure the Content Organizer Feature

This core action enables us to move a document to another library within the same site collection using a SharePoint web service named Official File. In order to enable this web service endpoint, we need to enable a site feature and configure some content rules.

We first activate this feature by visiting this page:

• Click on site setting
• Click on site features
• Look for Content Organizer and activate this feature

Content Organizer Rules

Create metadata based rules that move content submitted to this site to the correct library or folder.

This enables the web service that we can use to move the document. The end point is found at a location relative to your site collection for example:

_vti_bin/OfficialFile.asmx  or  sites/demo/_vti_bin/OfficialFile.asmx

Note:  We use this address when we add the workflow action.

This web service address can also be found by visiting the following page: 

• Site Settings
• Under Site Administration select Content Organizer Settings

Create the Content Rule

Now that the service is available to the site collection, we need to configure a rule that indicates what type of content type we want to manage and to what library we need to send this content. This is done by visiting the following page:

• Site Settings
• Under Site Administration select Content Organizer Rules

We want a rule for the Document content type, and we want to send the document to the ArchiveLibray.  As we can see, here we could route documents based on custom content types to other libraries.

Note: When using custom content types, we can have a more granular set of rules to send documents to other libraries that are based on that content type.

Workflow Send to Document Repository Action

We have now setup all the requirements to be able to send or move our document to another location.  We can now add a workflow using SharePoint Designer.  On our first step, we want to add the Send Document to Repository action.

Note: SharePoint 2010 Workflows provide this action.

This workflow action has three parameters

Parameter	Description
This action	This allows us to indicate to copy or move the document.
This destination content organizer	This is needed to indicate where the web service is located. Use the address that was identified on the previous sections.
This explanation	Use this parameter to add some comment about the action.

In our example, we are deciding to move the document using our previously defined Content Organizer Web Service. In this example, there are no specific conditions to validate for this action, but this is the area we can validate a document status and run the action accordingly.

Summary

We have shown how to use the Content Organizer Web Service and a workflow action. With this approach there are more configuration steps that need to be complete in order to support the solution.  The additional configuration does bring added value as it can enable us to route documents based on their content type to other document libraries.

For cases where a simpler approach is desirable, we can refer to the article below which essentially shows us how to use the Copy and Delete core actions to implement a simpler Move action.

SharePoint 2013 Move Document with Copy and Delete Actions

I hope this is able to show you a way to move document across document locations using a workflow action and the Content Organizer Web Service.

Originally published by ozkary.com

SharePoint 2013 Workflow Move Documents With Copy and Delete Actions

 A common task for document management system is to move a document from one library to another when the document approval status meets some condition.  Unfortunately, there is no Move core action provided from the out of box functionality.  There is however other core actions that we can leverage to implement this solution.

Move Documents

Workflow Core Actions

When building our workflows, we can use a couple of actions that enable us to move a document from one document library to another.

Core Action	Description
Copy	Use this action to copy the document across document libraries Parameter Description This list The item to copy. Set to current item This list The target document library
Delete	Use this action to delete the document from a document library Parameter Description This list The document item to delete. Set to current item

Implementing a Move workflow

After adding a workflow using SharePoint Designer, we can add a couple of actions to the first step.

For the copy item action, we want to select the current item which is a reference to the document that triggers the workflow. We also select the document library where we want to copy the document. This action makes a copy of the document, so this means that the document is located in two different document libraries which may not be the intended behavior.

After the document is copied, we can delete the document from the current location using the Delete action and passing the current item as an argument. This should remove the other copy from the source document library.

In our example, we copy the current item to a Drop Off document library. Since we do not want a copy of the document on the source library, we then delete the current item.

CodeProject

Note:  Current item is the scope object reference to the document that triggers the workflow.

Summary

We have shown that a move action can be implemented using the Copy and Delete core actions. For some use cases, this may not be a correct implementation since this creates a copy of the document and a different document id which uniquely identifies a document in the system.

 When this behavior does not meet our requirements, there is another core action that we can use to actually move the document. This approach however comes at a cost of more configuration complexity as well as the need to enable other site features.  We can read more about this on my next blog entry:

SharePoint 2013 Move Documents to Another Library Using Content Organizer

I hope this is able to provide you with a simple approach to move a document from one document library to another.

Originally published by ozkary.com

SharePoint Create a host-named Site with PowerShell

On SharePoint, we usually create site collections using the path-based route. This approach aligns very well with the SharePoint online/Office 365 site structure recommendations. With SharePoint 2013, we can create a site collection using a host-named site which allows us to assign a unique DNS name to our site collections. This enables us to deploy multiple sites with different DNS names in the same web application.

CodeProject

Path-named vs Host-named

Site Collection Structure	Example
Path-named	ozkary.com/sites/demosite1
Host-based	demosite1.ozkary.com

In order to deploy a host-named site, we need to create a DNS entry that points to the SharePoint host server/farm. We then need to write some code using PowerShell as this feature is not available from the Admin Central.

To create the site collection, we run this custom function from PowerShell with elevated permissions.

#

# Name: createHostNamedSite

#

# Description:  Creates a host-named site collection

# Usage

# createSite web-app-name, dns-entry site-name site-description admin-account-name site-template content-database

#

createHostNamedSite "ozkary.com" "https://demosite1.ozkary.com" "Demo Site 1" "Demo Site 1 Description" "admin-account" "STS#0" "WSS_Content_DB"

Parameter Information

Parameters	Description
Web-app-name	Main SharePoint web app name where site collections are hosted
Dns-entry	The unique DNS entry for the site
Site-name	The name for the site collection
Site-description	The site description
Admin-account-name	The site collection owner usually the admin
Site-template	A site template like team site, document center Click here to see more templates
Content-database	The content database for this site collection

createHostNameSite Function

Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue

#

#  Name: createHostNameSite

# 

#  Description: create a host-named site collection

#

#  Params:

#       $webAppName 

#       $siteUrl

#       $siteName

#       $description

#       $owner

#       $template

#       $contentDatabase 

#

function createHostNameSite($webAppName, $siteUrl, $siteName, $description, $owner,$template, $contentDatabase)

{   

    write-host "Creating site with parameters " $webAppName, $siteUrl, $siteName, $description, $owner,$template, $contentDatabase , $mapUrl

    $continue = Read-Host -Prompt "Do you want to continue (y/n)"

    if ($continue -eq "y")

    {

        write-host "Provisioning Site...."       

        New-SPSite $siteUrl  -Name $siteName -Description $description -OwnerAlias $owner -Template $template  -ContentDatabase  $contentDatabase  -HostHeaderWebApplication (Get-SPWebApplication $webAppName)               

    }else{

        write-host "Process cancelled"

    }

}

On the code , we first include the SharePoint plug-in which enables us to use the New-SPSite cmdlet that handles all the hard work for us.  Another area to notice is that there is the HostHeaderWebApplication parameter for which we pass the SharePoint web application reference by using the Get-SPWebApplication cmdlet. This is what enables us to create the host-named site.

After the site is created, we should be able to type the DNS name, and if it is already created and propagated in your network, the request should be able to be sent to SharePoint which can load the corresponding site properly.

I hope this is helpful and enjoy your site creation automation (DevOps) with PowerShell. 

Originally published by ozkary.com