I launched Cloud Release on Google Play

On the 8th of November, I submitted an Android app on Google Play named Cloud Release. Google published the app to the store on the 11th November and it is currently available in 10 countries.

As a Microsoft Azure Cloud Architect, it was important for me to keep up to date with all the latest previews, developments and releases into the Microsoft Azure cloud platform which is why I have created the Android app, so that I can easily be kept informed of all Microsoft Azure updates. I’ve kept the layout simple, in a listview, with a web browser view to launch directly into the published article from Microsoft. This enables me to keep up to date on a regular basis on all recent developments in Microsoft Azure in one place. I developed the app during my train journey’s and in some of my spare time in the evenings and I’m delighted to release it free to the Google Play store. I’ll be releasing new features over time, but for now this is what the app provides.

  • Synchronisation of the latest articles on the application launch
  • A local database is used for all downloaded articles
  • Quick search feature to query the local database
  • Direct Web browser view, to review the full article on the Microsoft docs web site

You can download the app free from the Google Play store here.


A focus on Azure Security Options

A number of options are available for Microsoft Azure security solutions and as part of planning your azure subscriptions. There are a number of options any customer should consider.

I have put together a small whitepaper which introduces some of the key concepts and solutions which should be considered for any cloud deployment.

You can download my published whitepaper below.


Azure VNet Peering

I’ve recently been reviewing VNet peering for Azure in detail and if you have VNet VPN gateways today, it’s time to switch to VNet peering if you have VNets connected together with the old method, especially now that it is in general availability. This is only a consideration for VNet’s connected in the same region as currently VNet peering is not available across Azure regions e.g. UK West and UK South.

VNet peering allows you to connect two or more Azure VNet’s together with a few simple steps vs the old method of provisioning gateway subnets and VPN Gateways. You also don’t have to provision a VPN gateway for VNet peering as the traffic travels through the Azure backbone and not through a site-to-site (S2S) IPSEC VPN tunnel. This obviously has numerous benefits, with Azure regional virtual networks that have provide the appropriate infrastructure for high bandwidth use. VNet-to-VNet connections always had limited connectivity based on the gateway type that was provisioned.

You can follow the Microsoft Azure article below if you have a need to provision VNet-to-VNet connections using VPN gateways, based on your requirements e.g. you need to connect two VNet’s together in different Azure regions.

Configure a VNet-to-VNet connection using the Azure portal

Here’s my example of how to create two Azure VNet’s and peer them using PowerShell. I’ll wrap these into my custom Azure PowerShell module in a couple of functions, with the appropriate  parameter input types, for future use.

# Login to Azure
# Use Select-AzureRmSubscription to select the subscription you want to create the VNets into

# New resource group in the location where we will hold all the resources
New-AzureRmResourceGroup -Name RG-VNETS -Location ukwest

# Create Virtual Network A with a subnet in the UK West Region
$NSGSubNetA = New-AzureRmNetworkSecurityGroup -Name NSG-SubNetA -ResourceGroupName RG-VNETS -Location ukwest
$SubNetA = New-AzureRmVirtualNetworkSubnetConfig -Name SubnetA -AddressPrefix -NetworkSecurityGroup $NSGSubNetA
$VNetA = New-AzureRmVirtualNetwork -Name VNETA -ResourceGroupName RG-VNETS -Location ukwest -AddressPrefix -Subnet $SubNetA

# Create Virtual Network B with a subnet in the UK West Region
$NSGSubNetB = New-AzureRmNetworkSecurityGroup -Name NSG-SubNetB -ResourceGroupName RG-VNETS -Location ukwest
$SubNetB = New-AzureRmVirtualNetworkSubnetConfig -Name SubnetB -AddressPrefix -NetworkSecurityGroup $NSGSubNetB
$VNetB = New-AzureRmVirtualNetwork -Name VNETB -ResourceGroupName RG-VNETS -Location ukwest -AddressPrefix -Subnet $SubNetB

# Add peering VNETA to VNETB (this initiates the peering)
Add-AzureRmVirtualNetworkPeering -Name Peering-VNETA-to-VNETB -VirtualNetwork $VNETA -RemoteVirtualNetworkId $VNETB.Id

Notice that the peering status is initiated.


We now need to create the peering from VNETB to VNETA.

# Add peering VNETB to VNETA (this completes the peering)
Add-AzureRmVirtualNetworkPeering -Name Peering-VNETB-to-VNETA -VirtualNetwork $VNETB -RemoteVirtualNetworkId $VNETA.Id

The peering is now complete.


Be aware of the additional settings that are available to peering connections shown below.


You can enable or disable virtual network access from a peered VNet.

Allow forwarded traffic: Allows traffic from the peered network, not originating from the peered network, into the local VNet.

Allow gateway transit: allows the peered VNet to use the gateway in the local VNet. The peered network “use remote gateways option” must be enabled. It will only be available if the local VNet has a gateway configured.

Use Remote Gateways: The VNet will use the remote peered VNet gateway, but the remote VNet must have the “Allow gateway transit option enabled”.


You cannot daisy chain VNets and expect them all to act as one address space with routing between then, regardless of the number of options you specify above. Daisy chaining isn’t really the best networking practice to follow in any case. I recommended that a hub and spoke topology is implemented with the appropriate security controls. I also recommended that you have Network Virtual Appliances (NVAs) in the hub as that will provide you with the most flexibility for controlling your network traffic between the VNet’s and subnets. Managing lots of NSG’s can be very cumbersome, but this depends on your release mechanism and experience as you could still use ARM templates to manage updates to NSGs.

The most common NVAs are CheckPoint vSEC, Barracuda NextGen and Fortinet FortiGate. For further information see the Microsoft Azure Docs article below.

Deploying high availability network virtual appliances

For further information on VNet Peering, you can review Microsoft Azure Docs overview article below.

VNet Peering


Shared Responsibilities: Cloud Computing

Whilst implementing security controls in Microsoft Azure, it is also important to understand the shared responsibilities between cloud service providers and what the customer can configure and control in terms of networking and security for the services customers require. Responsibilities change when you work with SaaS, PaaS and IaaS. It’s also important to understand how Microsoft handles security response and the process which is followed..

Alice Rison, Senior Director, Microsoft Azure has just published details on two recent whitepapers which were recently released to provide insight into the shared responsibilities and security response at Microsoft.

The published papers can be found linked to this announcement here: Microsoft Incident Response and shared responsibility for cloud computing

Azure NSG Rules:Beware

Recently, I had reviewed an issue with a load balancer which was not working correctly in Azure IaaS. This load balancer was specifically created in Azure Resource Manager (ARM) and it was load balancing a SQL Server AlwaysOn Availability Group (AOAG) listener. Client connections would fail to connect to the SQL Server standard TCP port 1433, through the load balancer, but would be accessible from to host with a direct reference.

After a fair amount of troubleshooting, Network Security Group (NSG) rules were preventing the load balancer from working correctly. The default rules in NSGs are set at a very high priority, which do allow load balancers to access the local virtual networks. This is currently defined in the default rule highlighted below. The source tag AzureLoadBalancer is used to allow a destination of any with any service/port on the NSG.


The rule which blocked the load balancer from functioning correctly has been shown below.


Creating a rule blocking a source tag of Internet with destination any and service of any with any source/target port ranges of any, rendered the load balancer inoperable. The rule is actually not required since the default DenyAllInBound rule would block any internet traffic. Besides, you would need to either load balance requests or NAT traffic from the internet to the local subnet or host in order to have the appropriate communication pass through.

When you define your NSGs and apply these to subnets or host network interfaces, be aware that you have the capability to block Azure services from working correctly.

Manage the security architecture correctly and ensure that you design your NSGs based on your requirements, also be aware of the default NSG rules which are implicitly implied.

Azure IaaS Guidance, the basics…

The importance of planning and designing in Azure IaaS is just as important as in the days you designed your own on premises infrastructure. Azure has many capabilities which all rely on dependent resource models when you design your application infrastructure to support your projects. With any platform, private or public cloud, you need to ensure that you follow the appropriate guidance around the principles which are focused on best practices for successful implementations of cloud projects. As you would do with any infrastructure design project, there are common components which are key to how you design your applications to achieve operational excellence and performance. Some of the key basic elements have been outlined below.

Data Center Azure IaaS
Physical Machine/Virtual Machine Azure Virtual Machine
SAN Available through Storage Accounts (Tables, Queues, Blobs)
LAN Multiple Virtual Networks with Subnets
WAN/VPN enablement ExpressRoute/VPN Gateway
Network Security Polices Network Security Groups


Ingredient 1: VM Sizing

With all the current VM sizes in Azure it can be complicated to start with sizing your requirements up front. It’s important to review your application requirements and how you intend to deploy your overall architecture and instances to support your needs throughout the project and application lifecycle. If you don’t need load balancing and you have some simple VM requirements you can start with A series VMs. If you need something more powerful with additional features like load balancing, you’ll need to move to the standard tier VMs. For intensive compute applications like SQL Server, especially if you are expecting high transactional loads, you should move up to at least the D or DS series VMs. The G series and GS series offer most performance, more disks, larger temporary disks and RAM with the most powerful processors today. Each tiered VM has different capabilities with the number of CPU cores and speed, disk bandwidth and maximum number of attached data disks and virtual network interface adapters. You also need to be aware of the disk limits and I/O limits of each VM size, the number of data disks that you could attach and the max number of IOPS each VM can support with the appropriate storage account type.

It’s important to note that premium storage is only available for use with the DS and GS series VMs. They also use solid state drives for improved I/O, the same as premium storage.

For further information, see https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-size-specs/.

Ingredient 2: Storage

Once you’ve sized your VMs, storage is key to application performance and based upon IOPS requirements. If you have an idea of IOPS requirements for your applications, then life is much simpler in designing your storage requirements. Azure storage comes with different capabilities, tables, queues and blobs. For VMs, you will use storage accounts with blob storage. Each Virtual Hard Disk (VHD) is stored as a page blob. With Azure storage you have the choice of choosing Locally Redundant Storage (LRS), Zone Redundant Storage (ZRS), Geographically Redundant Storage (GRS) and Read Access Geographically Redundant Storage (RA-GRS). All these redundancy options need to be taken into consideration when you design your storage strategy in Azure for your VMs.

You also need to be aware of the max number of supported VHDs for your VMs in the storage accounts. Not to say that with a standard storage account you can have up to 500TB of space which could hold many VHDs, but you need to determine how many storage accounts you need as part of your design. For example, if you have multiple VMs and data disks and you use one storage account, each VM based on tier has max IOPS to each disk. If you had all your VHDs in one storage account you would end up with throttling your throughput because standard storage account can only support a number of highly utilised disks before throttling occurs. Premium storage with the DS and GS series VMs considerably improves your latency, but your storage space is currently reduced to 35TB per storage account.

With standard tier storage you pay for the data written to the VHD, regardless of the VHD size, each up to 1023GB. With premium storage, you have to create the data disks and you are charged for the whole size up front, unlike standard storage.

For further information, see https://azure.microsoft.com/en-gb/documentation/articles/storage-scalability-targets/ and https://azure.microsoft.com/en-gb/documentation/articles/storage-introduction/.

Ingredient 3: Network

How you design your Virtual Networks and Subnets is important from a number of aspects. You need to think about isolating your resources and how they will be accessed and by whom. The most common theme I have utilized is to ensure that you group your resources into Subnets which take more sense from an application perspective and tie these with security policies. For example, you wouldn’t have VMs exposed in a Subnet to a public IP address which don’t need to be part of a traditional DMZ in your data center. You would do exactly the same in Azure Virtual Networks and segment your virtual network design around your applications and accessibility requirements for your applications. Another way to think about segmentation around applications is to have front end, middle tier and backend Subnets for each set of groups of resources.

For further information, see https://azure.microsoft.com/en-gb/documentation/articles/virtual-networks-overview/.

For on premises connectivity you should consider ExpressRoute or VPN options with VPN Gateways. Each solution offers it’s own benefits.

For further information, see https://azure.microsoft.com/en-gb/documentation/articles/vpn-gateway-about-vpngateways/

Ingredient 4: Security

Security can be managed in different ways in Azure, with virtual appliances available through the VM depot, network security groups, endpoints, load balancers, firewalls, group policies etc. This is a very large area to consider and is of highest importance in any environment. As part of your blueprint and building our logical design, ensure that you take deep consideration into network security groups which can be applied to VMs, Network Interfaces and Subnets. A series of Access Control Lists (ACL’s) can be applied to the resources I mentioned earlier as part of a defence-in-depth strategy. Cloud security should be layered from the VMs, VM firewall, network isolation, access control lists and any protection that can be provided by virtual appliances. You can also force tunnel connections through your on premises environment if you are extending to Azure from your data center and mange traffic to the internet from on premise network security appliances..

For further information, see https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-nsg/.

Ingredient 5: Deployment

The deployment aspects of the cloud can be achieved in different ways. You can use the Azure Portal, Azure PowerShell Cmdlets, Azure Command Line Interface (CLI) and a combination of the highly recommended deployment method with Azure Resource Manager (ARM) templates. In Azure IaaS V1, we focused on Cloud Services as a container for resources. In ARM (IaaS v2), you focus on the whole application, or pieces of the deployment which makes up your footprint for your application architecture. There are a number of ARM templates available on GitHub to get you started. I would recommend building your own ARM templates to understand how the templates glue together before using ARM templates which might be complex. ARM allows you to define your blueprint and deploy this in a repeatable consistent manner, which is perfect for testing your deployments through the application lifecycle. There are certain elements you need to be aware of when you use ARM, for example your storage account deployment will fail if you don’t use lowercase alphanumeric characters from 3-24 characters. Something which isn’t debugged by Visual Studio when you develop the template, so be aware of some of the rulesets you need to follow.

For more information, see https://azure.microsoft.com/en-gb/documentation/articles/resource-group-overview/.

For Quickstart ARM templates to get you up and running, see https://azure.microsoft.com/en-gb/documentation/templates/.

That’s the end of the IaaS basics starter post for today, I hope you found it informative.

SharePoint 2013 Hybrid Disaster Recovery Approach with Azure IaaS

Over the past few months I’ve been working with the content team in Redmond to publish a hybrid disaster recovery approach for SharePoint 2013 with SQL Server AlwaysOn Availability Groups with Microsoft Azure. Today, the article was published and can be found below.

Plan for SQL Server AlwaysOn and Microsoft Azure for SharePoint Server 2013 Disaster Recovery

I’d ike to acknowledge the following people who provided valuable assisance in testing, reviewing and publishing the article on TechNet with me over the past few months in order to get this published in the detailed form that it is today.

Neil Hodgkinson, Senior Program Manager

Dan Wesley, Senior Content Editor

Steve Hord, Senior Content Editor

David Williams, SQL Server Expert

Matthew Robertshaw, SQL Server Expert

Azure IaaS: Workflow Manager Farm

Recently, I had a requirement to host and test a Workflow Manager farm in Azure IaaS with SharePoint 2013. The key element here was to ensure high availability for the SharePoint farm and the Workflow Manager farm as part of the design. This can be achieved by appropriately spreading your farm tier across availability sets, to ensure that the appropriate roles are available during host patching. This, of course, would include the database tier, where you could utilize SQL Server AlwaysOn Availability Groups in synchronous commit mode to achieve maximum uptime.

Cloud Services Generally, you would want to have separation between the SharePoint farm, SQL infrastructure and the workflow manager farm. I personally would recommend using the new regional networks in Azure so that you can utilize internal load balancers required for Workflow Manager high availability. The picture below depicts a very basic farm with high level components, including Workflow Manager within its own cloud service.


Internal load balancers are used for SQL Server AlwaysOn, currently supporting one AG in Windows Azure since the Internal Load Balancer (ILB)  supports only one IP address. The SharePoint farm would access SQL Server ideally via a DNS record pointing to the load balanced IP. The SQL Servers would expose the SQL Server endpoint port to the internal load balancer used by the SQL Server Availability Group for connectivity. Synchronous commit mode is utilized on the Availability group to maximise uptime. Since this topic is about Workflow Manager high availability, we would have three instances hosted within a cloud service being exposed via a internal load balancer. This should ideally be on port 12290 (https) for the farm to communicate to the Workflow Manager endpoint. It’s recommended to utilize a domain certification authority (CA), to have a trusted certificate between all the Workflow Manager nodes and Workflow clients. A common question is why would we just not have two servers in the Workflow Manager farm? Basically, Service Bus, utilizes a quorum, so a third node is required for High Availability.


  • Prior to configuring the Workflow Manager farm, ensure you have all the Azure VMs provisioned as part of a cloud service and install the Workflow and Service Bus, with the refresh versions and Service Bus 1.1. All nodes in the farm should have the same bits installed, otherwise your configuration may fail.
  • Ensure each host has a certificate issued by a domain CA and you have the certificate installed on all three nodes. The certificate must be trusted by the SharePoint Servers, otherwise you’d have a JSON download error message when you try and register and configure the Workflow Manager Proxy
  • Ensure you have a DNS Host (A) entry created, pointing to the ILB IP address,  in the domain which is tied to the common name issued by the domain CA (after you create the Internal Load Balancer)
  • The workflow manager installer account must be a local administrator on all three farm nodes
  • The workflow manager installer account must have the Server Admin role in SQL Server, although I have made this work with DBCREATOR and SECURITY ADMIN in the past, the Workflow Manager articles still suggest the SA role
  • The Workflow Manager RunAs Account must be a domain account and have the log on as a service right (make sure your domain policies do not override this security policy

Create the Internal Load Balancer in Azure

For this step you’ll require:

  • The Cloud Service Name
  • The VNet Subnet (for assigning the IP address to the ILB)

Run the following PowerShell to create the ILB:

# Internal Load Balancer Settings – replace these settings with your own environment settings

$ILBName = “ILBSBWorkflow”

$ILBSubnet = “WFSubNet”

$EndPointName = “IntSBWFEndPoint”

$WFHTTPSPort = “12290”

$PoleInterval = “20”

$ServiceName = “WORKFLOWCSVC”

$WFVM1 = “WF01”

$WFVM1 = “WF02”

$WFVM1 = “WF03”

# Add Internal Load Balancer to the service

Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $ILBSubnet -ServiceName $ServiceName

Expose and Assign the Endpoints to the ILB

Run the following PowerShell the create and expose the endpoint on the Virtual Machines, which participate in the load balanced set.

# Add load balanced endpoints to ILB for Workflow Manager

Get-AzureVM -ServiceName $ServiceName -Name $WFVM1 | Add-AzureEndpoint -Name $EndPointName -LBSetName $ILBName -Protocol tcp -LocalPort $WFHTTPSPort -PublicPort $WFHTTPSPort -ProbePort $WFHTTPSPort -ProbeProtocol tcp -ProbeIntervalInSeconds $PoleInterval -InternalLoadBalancerName $ILBName | Update-AzureVM

Get-AzureVM -ServiceName $ServiceName -Name $WFVM2 | Add-AzureEndpoint -Name $EndPointName -LBSetName $ILBName -Protocol tcp -LocalPort $WFHTTPSPort -PublicPort $WFHTTPSPort -ProbePort $WFHTTPSPort -ProbeProtocol tcp -ProbeIntervalInSeconds $PoleInterval -InternalLoadBalancerName $ILBName | Update-AzureVM

Get-AzureVM -ServiceName $ServiceName -Name $WFVM3 | Add-AzureEndpoint -Name $EndPointName -LBSetName $ILBName -Protocol tcp -LocalPort $WFHTTPSPort -PublicPort $WFHTTPSPort -ProbePort $WFHTTPSPort -ProbeProtocol tcp -ProbeIntervalInSeconds $PoleInterval -InternalLoadBalancerName $ILBName | Update-AzureVM

Create your DNS host entry to point to the load balanced address for Workflow Manager. To determine the IP address of the ILB, if you have not assigned one yourself when you created the ILB, you can run the following PowerShell:

Get-AzureInternalLoadBalancer -ServiceName $ServiceName

Install and configure the first Workflow Manager node and join the remaining nodes to the Workflow Manager farm. Check the farm is operational by running the following PowerShell:



Register the Workflow Manager Proxy

$SPWebApp = “https://webapplication”
$SPWorkFlowHostURI = “https://WORKfLOWADDRESS:12290”
Register-SPWorkflowService -SPSite $SPWebApp -WorkflowHostUri $SPWorkFlowHostURI

SharePoint App-only Policy Apps

SharePoint App-only Policy Apps

In the new world of Apps for SharePoint 2013 there is an app-only policy available to allow SharePoint Apps to make requests to SharePoint sites, on premise or SharePoint Online, without user intervention if necessary. So why is this so important in the Cloud App Model (CAM)?

Well, one case is where you may have a middle tier of web services which return SharePoint information that is accessible by a specific set of web clients that do not necessarily need the access to the SharePoint repositories directly or may be external systems making updates or retrieving data from SharePoint that may have no authenticated way of calling the SharePoint without that middle tier. In this case the SharePoint App would have the necessary permissions to retrieve or write data back to the SharePoint repositories without the calling application requiring access. The calling application would only need access to the middle tier web services in order to retrieve the underlying repository data. The middle tier could be secured differently, via certificates or Active Directory.

Another instance could be something like a re-occurring timer job that may need to perform some actions on the SharePoint repository on a regular basis e.g. a timer job or possibly a newsletter flyer being emailed based on information held in a SharePoint repository.

So how do we get this app-only policy and SharePoint App bolted together in order to make use of this new feature in the CAM world? It’s actually very simple and in this blog post I aim to provide you with a sample to work with to get you going.

First we need a scenario….


A timer job is required to log how many items there are currently in a SharePoint list which require pending actions. An administrator reviews a list which the SharePoint App writes to on a regular basis to inform them of the number of items that are pending actions.

A simple scenario but something to work from to demonstrate the SharePoint App-only policy. For the purposes of making it really simple, I have created a console app sample that uses the app-only policy.

Important Notes

In order to install an App which uses the app-only policy, the user must be a site collection administrator to grant the app-only policy.

Apps that do not make OAuth authenticated calls cannot use the app-only policy. The app-only policy is only available in apps that run out side of SharePoint, provider-hosted or auto-hosted (SharePoint Online) app, basically not apps which are SharePoint-hosted and using the JSOM library.



Ensure you include the tokenhelper.cs file in your solution.

Include references to Microsoft.SharePoint.Client and Microsoft.SharePoint.Client.Runtime

1)     Register the console app in the site collection (Office 365 or SharePoint On Premise)


Register the details below and ensure you generate the ClientId and Client Secret, also add the app title and app domain as required. There is no re-direct URL required.



2)      Browse to the site collection (Office 365 or SharePoint On Premise)


3)      Enter the app id (ClientId) generated in the appregnew.aspx page


4)      Enter the permissions xml, references to permission polices can be found here: http://msdn.microsoft.com/en-us/library/office/fp142383(v=office.15).aspx

I allowed the app to have Full Control rights at the web level with the “AllowAppOnlyPolicy” set to “true”.

<AppPermissionRequests AllowAppOnlyPolicy="true" >

<AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />

</AppPermissionRequests>The app is now registered.

6)      After you click Create you should trust the app that was registered.


5)      Update your app.config file with the following section and apply the appropriate ClientId and ClientSecret Note that, getting any of these incorrect may cause a 400 bad request. If you debug the error, the tokenhelper.cs will fail at the following code:


<addkey="ClientId"value="generated ClientId"/>

<addkey="ClientSecret"value="generated ClientSecret"/>


Bad Request Error: If you debug the error, the tokenhelper.cs will fail at the following code when the tokenhelper class tries to receive a valid OAuth response.

OAuth2AccessTokenResponse oauth2Response;



oauth2Response =

client.Issue(AcsMetadataParser.GetStsUrl(targetRealm), oauth2Request) asOAuth2AccessTokenResponse;


6)  You can also generate the permission request XML by adding a SharePoint App and updating the permission to allow the app to make app-only calls to SharePoint and generate the appropriate scoped permissions. Then you could view the code in the appmanifest.xml file and copy the relevant generated code. If you are new to this I would recommend following this described step.
7)      Add the appropriate code to get a app-only token.

privatestaticvoid Main(string[] args)


ServicePointManager.ServerCertificateValidationCallback =

newRemoteCertificateValidationCallback(delegate { returntrue; });

var siteURL = "https://tenantdomain.sharepoint.com/sites/sitecollection";

Uri siteUri = newUri(siteURL);

// Get the realm for the URL

string realm = TokenHelper.GetRealmFromTargetUrl(siteUri);

//Get the access token for the URL

string accessToken = TokenHelper.GetAppOnlyAccessToken(


siteUri.Authority, realm).AccessToken;

// Get client context with access token

using (var clientContext =


siteUri.ToString(), accessToken))


Web web = clientContext.Web;

clientContext.Load(web, w => w.Title);


var title = web.Title;





The sample code above displays the web title in the console application.

Getting our pending action items from the documents list

Now lets add the code for the sample to return items from a document library to query pending items.

In the site collection the default document library has 3 items which have a different pending status. The pending column is our flag that an item requires actions. The library items are shown below.


The code required to query the list appropriately can be added in the section where a client context has been generated (clientContent). We use the clientContext with the app-only access token to retrieve the information from the list based on the app permissions specified earlier.

The code has been documented below.

// Get client context with access token

using (var clientContext =


siteUri.ToString(), accessToken))


Web web = clientContext.Web;

// Retrieve the List from the web

List documents = clientContext.Web.Lists.GetByTitle("Documents");

var pendingItemsQuery = @"<View><Query><Where><Eq><FieldRef Name='Pending'/><Value Type='Integer'>1</Value></Eq></Where></Query></View>";

CamlQuery listQuery = newCamlQuery();

listQuery.ViewXml = pendingItemsQuery;

ListItemCollection documentListItems = documents.GetItems(listQuery);



if (documentListItems.Count > 0)


Console.WriteLine("Items that have pending actions are listed below");

foreach (ListItem li in documentListItems)







Console.WriteLine("No pending items in documents list.");



Console.WriteLine("Press any key to exit");


Returned Console Output

The output of the query is listed below.


The executable can be scheduled using the Windows task scheduler to perform the required functions on a provider hosted server. The app is trusted via OAuth (ClientId and ClientSecret), which registered at the site collection level. To make the deployment easier, you could include a SharePoint app project in the solution and register the app to be deployed to any site collection via the app catalog. Should you need to query more site collections, you could change the scoped permissions to the tenant or deploy the app at each site collection.

A simple solution to have an application query SharePoint sites in Office 365 or SharePoint 2013. The solution can be extended to update a logging list for the administrator to log pending actionable items.The Client side Object Model (CSOM) could be utilized to perform whatever functions are required for any app of this nature.


SQL Server 2012 Availability Group Demonstration

I’ve created a short video post for this blog entry to demonstrate how to:

  • Add a cluster node, with single PowerShell command, to an existing Windows Server 2012 Cluster
  • Enable SQL Server AlwaysOn Availability Groups (AG) in a SQL Server 2012 instance
  • Create a sample database and add some records for testing SQL Server Async-commit replica propagation
  • Demonstrated a custom tool to return the record count from primary and secondary replicas
  • Walked through the pre-requisites for enabling SQL Server AlwaysOn AG


SQL statements to create and add sample records to the CoolCars database.






CREATE TABLE [dbo].[CarList](
[ID] [int] NOT NULL,
[Manufacturer] [nvarchar](50) NOT NULL,
[Model] [nvarchar](15) NOT NULL,
[ModelYear] [nvarchar](4) NOT NULL,
[ExteriorColour] [nvarchar](15) NOT NULL,
[Miles] [int] NOT NULL,
[Transmission] [nvarchar](20) NOT NULL,
[Price] [money] NOT NULL,
[InteriorColour] [nvarchar](15) NOT NULL,
[Doors] [int] NOT NULL,
[Type] [nvarchar](50) NOT NULL,
[Picture] [image] NULL,
CONSTRAINT [PrimaryKey_883d618c-922d-4695-98d4-c4e79c5871d7] PRIMARY KEY CLUSTERED



VALUES ('1','Ferrari','F355','1999','Red','20000','Manual','56000','Black','2','Spider')
VALUES ('2','Ferrari','F355','1995','Blue','22000','Manual','46000','Black','2','GTB')
VALUES ('3','Ferrari','Enzo','2006','Black','2000','Paddle Shift','225000','Red','2','Spider')
VALUES ('4','Ferrari','438','1992','Yellow','26000','Manual','35000','Black','2','TB')
VALUES ('5','Ferrari','F355','1997','Yellow','40000','Manual','3000','Red','2','Berlinetta')
VALUES ('6','Porsche','Carerra','2008','Silver','15000','Automatic','78000','Black','2','GT4')
VALUES ('7','Ferrari','308','1985','Red','60000','Manual','15000','Black','2','GTO')
VALUES ('8','Lamborghini','Diablo','1994','Blue','66000','Manual','120000','Black','2','Coupe')
VALUES ('9','Aston Martin','DB9','2008','Black','10000','Automatic','5544','Grey','2','Spider')
VALUES ('10','BMW','545','2010','Black','40000','Paddle Shift','76000','Grey','4','M')
VALUES ('11','Ferrari','F355','1999','Red','20000','Manual','56000','Black','2','Spider')
VALUES ('12','Ferrari','F355','1995','Blue','22000','Manual','46000','Black','2','GTB')
VALUES ('13','Ferrari','Enzo','2006','Black','2000','Paddle Shift','225000','Red','2','Spider')
VALUES ('14','Ferrari','438','1992','Yellow','26000','Manual','35000','Black','2','TB')
VALUES ('15','Ferrari','F355','1997','Yellow','40000','Manual','3000','Red','2','Berlinetta')
VALUES ('16','Porsche','Carerra','2008','Silver','15000','Automatic','78000','Black','2','GT4')
VALUES ('17','Ferrari','308','1985','Red','60000','Manual','15000','Black','2','GTO')
VALUES ('18','Lamborghini','Diablo','1994','Blue','66000','Manual','120000','Black','2','Coupe')
VALUES ('19','Aston Martin','DB9','2008','Black','10000','Automatic','5544','Grey','2','Spider')
VALUES ('20','BMW','545','2010','Black','40000','Paddle Shift','76000','Grey','4','M')
VALUES ('21','Ferrari','4+4','2012','Red','30000','Paddle Shift','16000','Black','2','coupe')
VALUES ('22','Ferrari','4+4','2012','Red','30000','Paddle Shift','16000','Black','2','coupe')
VALUES ('23','Ferrari','F430','2007','Red','2342','Paddle Shift','98000','Black','2','Spider')
VALUES ('24','BMW','545','2010','Black','40000','Paddle Shift','76000','Grey','4','M')
VALUES ('25','Ferrari','4+4','2012','Red','30000','Paddle Shift','16000','Black','2','coupe')

C# code for the sample Windows Forms application to check the record count in the primary and secondary SQL instances.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Data.SqlClient;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace CoolCarsSQLDemo
    public partial class Form1 : Form
        public Form1()

        private void btnGetPrimarySQLCount_Click(object sender, EventArgs e)
                lblClusterCount.Text = getRecordCountfromSQLServer("<SOURCESQLSERVER>", "CoolCars", "CarList");
            catch { }

        private void btnGetDRSQLCount_Click(object sender, EventArgs e)
                lblDRCount.Text = getRecordCountfromSQLServer("<DRSQLSERVER>", "CoolCars", "CarList");
            catch { }

        public string getRecordCountfromSQLServer(string SQLServerName, string DataBase, string TableName)
            string result = "";
            SqlConnection DBConnection = new SqlConnection("Server=" + SQLServerName + ";Database=" + DataBase + ";Trusted_Connection=True;");
                SqlCommand myCommand = new SqlCommand("SELECT Count(*) from " + DataBase + ".dbo." + TableName, DBConnection);
                var count = myCommand.ExecuteScalar().ToString();
                result = count;
            catch (Exception ex)
                var exception = ex.ToString();
                string error = "Error Occurred";
                return error;
            return result;