Use Azure VMs with On Premises Gateway as SP2010 Branch Office Farm

Here are some notes from my ongoing experience of setting up a SharePoint 2010 "branch office" farm in Azure using the current preview of persistent Azure virtual machines in a Azure virtual network connected to the on premises Active Directory using an Azure gateway to a Juniper VPN device.

Useful TechEd Europe 2012 web-casts that show how things work in general:
VM+VNET in Azure: http://channel9.msdn.com/Events/TechEd/Europe/2012/AZR208
AD in Azure: http://channel9.msdn.com/Events/TechEd/Europe/2012/SIA205
SP in Azure: http://channel9.msdn.com/Events/TechEd/Europe/2012/OSP334

Step by step instructions that I followed:
How to Create a Virtual Network for Cross-Premises Connectivity using the Azure gateway.
How to Install a Replica Active Directory Domain Controller in Windows Azure Virtual Networks.

Creating a virtual network (vnet) is easy and simple using the Azure preview management portal. I recommed creating the local network first, as the vnet wizard otherwise might fail - without giving any useful exception message. We had an issue caused by naming the local network "6sixsix" which didn't work due to the name starting with a digit. Also note that the VPN gateway only supports one LAN subnet in the current preview.

Plan your subnets upfront and make sure that they don't overlap with the on premises subnets. Register both the existing on premises DNS server and the planned vnet DNS server when configuring the vnet. A tip here is that the first VM created in a subnet will get .4 as the last part of the IP address, so if your ADDNSSubnet is 10.3.4.0/24, then the vnet DNS will get 10.3.4.4 as its IP address. Note that you can't change the DNS configuration after adding the first VM to the network, this includes creating the Azure gateway which adds devices to the gateway subnet.

After creating the Azure virtual network, we created and started the Azure gateway for connecting to the on premises LAN using a Site-to-Site VPN tunnel using a secure IPSec connection. Creating the gateway takes some time as some devices or VMs are provisioned in the gateway subnet you specified. We then sent the public IP address of the gateway, plus the shared key and the configuration script for the Juniper VPN device to our network admin. The connection wouldn't come up, and to make a long story short, the VPN configuration needs the 'peerid' to be set to an IP address of a device in the gateway subnet. Our gateway subnet was 10.3.1.0/24 and after trying 10.3.1.4 first (see above tip), the network admin tried 10.3.1.5 and that worked. I'll come back to this below when telling you about our incident when our trial Azure account was deactivated by Microsoft.

With the Azure virtual network up and running and connected to the on premises LAN, I created the AD DNS virtual machine using the preview portal "create from gallery" option. As SP2010 is not supported on WS2012 yet, I decided to use the WS2008R2 server image in this Azure server farm. Note that you should use size "large" for hosting AD as you need to attach two data disks for storing the AD database, log files and system state backup.

I did not use powershell for creating this first VM, instead I manually changed the DNS setting on the network adapter (both IPv4 and IPv6) and then manually joined the to-be AD DNS VM to the existing domain. Note that while you're at it, also set the advanced DNS option "Use this connection's DNS suffix in DNS registration" for both network adapters. Otherwise you will get the "Changing the Primary Domain DNS name of this computer to "" failed" error when trying to join the domain.

Following the how-to for setting up a replica AD in Azure work fine, we only had some minor issues due to the existing AD being on WS2003. For instance, we found no DEFAULTIPSITELINK when creating a new site in AD, so we had to create a new site link first, then create the site and finally modify the site link so that it linked the Azure "CloudSite" and the LAN site. Then the dcpromo wizard step for AD site detection didn't manage to resolve against our WS2003 domain controller, just click "ok" on the error message and manually select the "CloudSite" in the "Select a site" page.

I really wanted to set up a read-only domain controller (RODC) to save some outgoing (egress) traffic and thus save some money, as this branch farm don't need a full fidelity domain controller. However, it is not possible to create a RODC when the existing DC is on WS2003, because RODC is a WS2008 feature. So for "Additional Domain Controller Options" we went with DNS and "Global Catalog" (GC). GC isn't required, but if not installed then all authentication traffic on login need to go all the way to the on premises DC. So to save some traffic (and money), and get faster authN in the branch farm, we added the GC - even if the extra data will drive up Azure storage cost.

The next servers in the farm were added using powershell to ensure that 1) the VM is domain joined on boot, and 2) that the DNS settings for the VM is automatically configured.

Here are some tips for using New-AzureDNS, New-AzureVMConfig and New-AzureVM:

• You can use the Azure vnet DNS server or the on premises DNS server with New-AzureDNS. I used the former.
• The New-AzureVMConfig Name parameter is used when naming and registering the server in AD and DNS. Make sure that the full computer name is unique across the domain.
• The New-AzureVM ServiceName parameter is used for the cloud DNS name prefix in the .cloudapp.net domain. It is also used to provision a "Cloud Service" in the Azure preview management portal. Even if multiple VMs can be added to the same service name (shared workload), I used uniqe names for the farm VMs (standalone virtual machine), connected using the vnet for load balancing.
• To get the built-in Azure image names, use this powershell to go through the images in the gallery until you find the one you're looking for:
         (Get-AzureVMImage)[1].ImageName

After adding the SQL Server 2012, web server and application server VMs using powershell, I logged in using RDP and verified that each server was up and running, domain joined and registered in the DNS. Note that the SQL Server image is not by default configured with separate data disks for data and log files. This means that the SQL Server 2012 master database etc is stored on the OS disk in this preview. You need to add data disks and then change the SQL Server file location configuration your self. Adding two data disks will require that the SQL Server VM is of size "large".

The next step was to intall SharePoint 2010 on the farm the next day. Thats when the trial account was deactivated because all the computing hours was spent. Even if you then reactivate the account, all your VM instances are deleted, keeping only the VHD disks. As Microsoft support says, it is easy to recreate the VMs, but they also tell you that the AD virtual machine needs a static IP which you can only get in Azure if you never delete the VM. Remember to recreate the VMs in the correct order so that they get the same IP addresses as before.

What is worse is that they also delete the virtual network and the gateway. Even if it is also easy to recreate these, your gateway will get a new public IP address and a new shared key, so you need to call your network provider again to make them reconfigure the VPN device.

I strongly recommend not using a spending capped trial account for hosting your Azure branch office farm. Microsoft deleted the VMs and the network to stop incurring costs, which was fine with non-persistent Azure VM Roles (PaaS) anyway, but not as nice for a IaaS service with a persistent server farm.

I recommend exporting your VMs using Export-AzureVM so that you don't have to recreate the VMs manually if something should happen. The exported XML will contain all the VM settings, including the attached data disks.

How to deatch Azure VMs to move or save cost: http://michaelwasham.com/2012/06/18/importing-and-exporting-virtual-machine-settings/

When we recreated the Azure virtual network and the gateway, the VPN connection would not come back up again. The issue was that this time the gateway devices had got different IP addresses, so now the "peerid" had to be configured as 10.3.4.4 to make things work.

Now the gateway is back up again, and next week I'll restore the VMs and continue with installing SP2010 on the Azure "branch office" farm. More notes to come if I run into other issues.

- - - continued - - -

Installing the SharePoint 2010 bits went smooth, but running the config wizard did not. First you need to allow incoming TCP traffic on port 1433 on the Azure SQL Server. Then the creation of the SharePoint_Config database failed with:

    Could not find stored procedure 'sp_dboption'.

...even if I had downloaded and installed SP2010 with SP1 bits. So I downloaded and installed SharePoint Server 2010 SP1 and June CU from 2011 due to the issue caused by using SQL Server 2012 and that fixed the problem. Got "Configuration Successfull" without any further issues.

Finally, I tested and verified it all by creating a SP2010 web-application with a team site, creating a self-signed certificate with IIS7 and adding an Azure port mapping for SSL (virtual machine endpoint, TCP 443 to 443), allowing me to login to the team site using my domain account over HTTPS from anywhere.

A note on the VM firewall config is that ping is by default blocked, thus you can't ping other machines in the vnet unless you configure the firewall to allow it. Also note that you can't ping addresses outside of the virtual network and the connected LAN anyway; even if you can browse to www.puzzlepart.com, you can't ping us.

SharePoint Publishing Site Map Providers and Navigation

Configuring the navigation of SharePoint 2010 publishing sites and subsites can be a bit confusing, also when configuring the navigation from code or from your web templates (or even old school site definitions). Add to that the UI that changes based on which settings you chose combined with what site or subsite context you're currently in. Plus the quite large number of site map providers defined in the web.config when using the PortalSiteMapProvider from code.

This post is about how the UI settings can be repeated in your site provisioning code, that is: first configure the navigation settings in your prototype to make it work according to your navigation concept, then package the settings into feature code.

The PortalSiteMapProvider works in combination with the PublishingWeb navigation settings, and of course with the top and current navigation controls used to render the navigation as HTML. The latter needs to look at the publishing web's PortalNavigation settings when querying the portal site map provider for the CurrentNode or when getting a set of navigation nodes to render. The navigation controls' code use the PortalSiteMapProvider properties IncludeSubSites, IncludePages, IncludeAuthoredLinks and IncludeHeadings to set the filtering applied to GetChildNodes when rendering nodes. These filter properties are typically set to IncludeOption.PerWeb to reflect the navigation settings of the current site or subsite.

The navigation settings UI tries to show the effects of your navigation settings (upper half) by rendering a preview of what nodes GetChildNodes would return for the *current* site (lower half) from the applicable site map provider. The PortalSiteMapProvider exposes several of the providers defined in web.config as static properties, but only two of them are typically used: CombinedNavSiteMapProvider and CurrentNavSiteMapProvider. The former is what feeds the top navigation, the latter feeds the current (left, local) navigation.

Note that when inheriting global navigation, the UI won't show the global navigation container as it only supports configuring the navigation of the current site. The term "parent site" in the UI refers to the top-level site of the site-collection, which is not the direct parent of a subsite beyond level 1 children.

Configuring the navigation settings from your site provisioning feature is quite simple once you've got a working prototype of your navigation concept. Use the mapping shown in the above figure to program the configuration settings for both global navigation (InheritGlobal, GlobalIncludeSubSites, GlobalIncludePages) and current navigation (InheritCurrent, CurrentIncludeSubSites, CurrentIncludePages, ShowSiblings).

The only little pitfall is for "Display the current site, the navigation items below the current site, and the current site's siblings" which requires a combination of InheritCurrent = false and ShowSiblings = true. Use this setting to show the same local navigation for a section of your web-site and all its child sites. A typical example is for the Quality Management section (level 1 subsite) and its QMS areas (level 2 subsites) to have a shared navigation experience. The QMS section would not use ShowSiblings while all the child areas would have ShowSiblings turned on.

Implementing a custom navigation concept is as simple as writing your own navigation rendering controls, and inheriting the PortalSiteMapProvider to override the logic for CurrentNode and GetChildNodes to suit your needs by applying the applicable node filtering properties to control which nodes are returned and rendered in which context. I've also used this approach for reading the navigation items from a central SharePoint list to get common cross site-collection top-navigation.

I hope this helped you understand how to realize your navigation concept from code, and that you're not totally confused by all the available site map providers and how they are used anymore.

Exploring Search Results Step-by-Step in SharePoint 2010

Using search to provide a news archive in SharePoint 2010 is a wellknown solution. Just add the core results web-part to a page and configure it to query for your news article content type and sort it in descending order. Then customize the result XSLT to tune the content and layout of the news excerpts to look like a new archive. Add also the search box, the search refiners and the results paging web-parts and you have a functional news archive in no time.

This post is about providing contextual navigation by adding "<< previous", "next >>" and "result" links to the article pages, to allow users to explore the result set in a step-by-step manner. Norwegians will reckognize this way of exploring results from finn.no.

For a user or visitor to be able to navigate the results, the result set must be cached per user. The search results are in XML format, and it contains a sequential id and the URL for each hit. This allows the navigation control to use XPath to locate the current result by id, and get the URLs for the previous and next results. The user query must also be cached so that clicking the "result" link will show the expected search results.

Override the CoreResultsWebPart as shown in my Getting Elevated Search Results in SharePoint 2010 post to add per-user caching of the search results. If your site allows for anonymous visitors, you need to decide on how to keep tab on them. In the code I've used the requestor IP address, which is not 100% foolproof, but this allows me to avoid using cookies for now.

namespace Puzzlepart.SharePoint.Presentation

{

    [ToolboxItemAttribute(false)]

    public class NewsArchiveCoreResultsWebPart : CoreResultsWebPart

    {

        public static readonly string ScopeNewsArticles 

            = "Scope=\"News Archive\"";

        private static readonly string CacheKeyResultsXmlDocument 

            = "Puzzlepart_CoreResults_XmlDocument_User:";

        private static readonly string CacheKeyUserQueryString 

            = "Puzzlepart_CoreResults_UserQuery_User:";

        private int _cacheUserQueryTimeMinutes = 720;

        private int _cacheUserResultsTimeMinutes = 30;

        protected override void CreateChildControls()

        {

            try

            {

                base.CreateChildControls();

            }

            catch (Exception ex)

            {

                var error = SharePointUtilities.CreateErrorLabel(ex);

                Controls.Add(error);

            }

        }

        protected override XPathNavigator GetXPathNavigator(string viewPath)

        {

            //return base.GetXPathNavigator(viewPath);

            SetCachedUserQuery();

            XmlDocument xmlDocument = GetXmlDocumentResults();

            SetCachedResults(xmlDocument);

            XPathNavigator xPathNavigator = xmlDocument.CreateNavigator();

            return xPathNavigator;

        }

        private XmlDocument GetXmlDocumentResults()

        {

            XmlDocument xmlDocument = null;

            QueryManager queryManager = 

            SharedQueryManager.GetInstance(Page, QueryNumber).QueryManager;

            Location location = queryManager[0][0];

            string query = location.SupplementaryQueries;

            if (query.IndexOf(ScopeNewsArticles, 

                StringComparison.CurrentCultureIgnoreCase) < 0)

            {

                string userQuery = 

                    queryManager.UserQuery + " " + ScopeNewsArticles;

                queryManager.UserQuery = userQuery.Trim();

            }

            xmlDocument = queryManager.GetResults(queryManager[0]);

            return xmlDocument;

        }

        private void SetCachedUserQuery()

        {

            var qs = HttpUtility.ParseQueryString

                    (Page.Request.QueryString.ToString());

            if (qs["resultid"] != null)

            {

                qs.Remove("resultid");

            }

            HttpRuntime.Cache.Insert(UserQueryCacheKey(this.Page), 

               qs.ToString(), null, 

               Cache.NoAbsoluteExpiration, 

               new TimeSpan(0, 0, _cacheUserQueryTimeMinutes, 0));

        }

        private void SetCachedResults(XmlDocument xmlDocument)

        {

            HttpRuntime.Cache.Insert(ResultsCacheKey(this.Page), 

               xmlDocument, null, 

               Cache.NoAbsoluteExpiration, 

               new TimeSpan(0, 0, _cacheUserResultsTimeMinutes, 0));

        }

        private static string UserQueryCacheKey(Page page)

        {

            string visitorId = GetVisitorId(page);

            string queryCacheKey = String.Format("{0}{1}", 

                CacheKeyUserQueryString, visitorId);

            return queryCacheKey;

        }

        private static string ResultsCacheKey(Page page)

        {

            string visitorId = GetVisitorId(page);

            string resultsCacheKey = String.Format("{0}{1}", 

                CacheKeyResultsXmlDocument, visitorId);

            return resultsCacheKey;

        }

        public static string GetCachedUserQuery(Page page)

        {

            string userQuery = 

                (string)HttpRuntime.Cache[UserQueryCacheKey(page)];

            return userQuery;

        }

        public static XmlDocument GetCachedResults(Page page)

        {

            XmlDocument results = 

                (XmlDocument)HttpRuntime.Cache[ResultsCacheKey(page)];

            return results;

        }

        private static string GetVisitorId(Page page)

        {

            //TODO: use cookie for anonymous visitors

            string id = page.Request.ServerVariables["HTTP_X_FORWARDED_FOR"] 

                ?? page.Request.ServerVariables["REMOTE_ADDR"];

            if(SPContext.Current.Web.CurrentUser != null)

            {

                id = SPContext.Current.Web.CurrentUser.LoginName;

            }

            return id;

        }

    }

}

I've used sliding expiration on the cache to allow for the user to spend some time exploring the results. The result set is cached for a short time by default, as this can be quite large. The user query text is, however, small and cached for a long time, allowing the users to at least get their results back after a period of inactivity.

As suggested by Mikael Svenson, an alternative to caching would be running the query again using the static QueryManager page object to get the result set. This would require using another result key element than the dynamic <id> number to ensure that the current result lookup is not scewed by new results being returned by the search. An example would be using a content type field such as "NewsArticlePermaId" if it exists.

Overriding the GetXPathNavigator method gets you the cached results that the navigation control needs. In addition, the navigator code needs to know which is the result set id of the current page. This is done by customizing the result XSLT and adding a "resultid" parameter to the $siteUrl variable for each hit.

. . . 

 <xsl:template match="Result">

    <xsl:variable name="id" select="id"/>

    <xsl:variable name="currentId" select="concat($IdPrefix,$id)"/>

    <xsl:variable name="url" select="url"/>

    <xsl:variable name="resultid" select="concat('?resultid=', $id)" />

    <xsl:variable name="siteUrl" select="concat($url, $resultid)" />

. . . 

The result set navigation control is quite simple, looking up the current result by id and getting the URLs for the previous and next results (if any) and adding the "resultid" to keep the navigation logic going forever.

namespace Puzzlepart.SharePoint.Presentation

{

    public class NewsArchiveResultsNavigator : Control

    {

        public string NewsArchivePageUrl { get; set; }

        private string _resultId = null;

        private XmlDocument _results = null;

        protected override void CreateChildControls()

        {

            base.CreateChildControls();

            _resultId = Page.Request.QueryString["resultid"];

            _results = NewsArchiveCoreResultsWebPart.GetCachedResults(this.Page);

            if(_results == null || _resultId == null)

            {

                //render nothing

                return;

            }

            AddResultsNavigationLinks();

        }

        private void AddResultsNavigationLinks()

        {

            string prevUrl = GetPreviousResultPageUrl();

            var linkPrev = new HyperLink()

            {

                Text = "<< Previous",

                NavigateUrl = prevUrl

            };

            linkPrev.Enabled = (prevUrl.Length > 0);

            Controls.Add(linkPrev);

            string resultsUrl = GetSearchResultsPageUrl();

            var linkResults = new HyperLink()

            {

                Text = "Result",

                NavigateUrl = resultsUrl

            };

            Controls.Add(linkResults);

            string nextUrl = GetNextResultPageUrl();

            var linkNext = new HyperLink()

            {

                Text = "Next >>",

                NavigateUrl = nextUrl

            };

            linkNext.Enabled = (nextUrl.Length > 0);

            Controls.Add(linkNext);

        }

        private string GetPreviousResultPageUrl()

        {

            return GetSpecificResultUrl(false);

        }

        private string GetNextResultPageUrl()

        {

            return GetSpecificResultUrl(true);

        }

        private string GetSpecificResultUrl(bool useNextResult)

        {

            string url = "";

            if (_results != null)

            {

                string xpath = 

                    String.Format("/All_Results/Result[id='{0}']", _resultId);

                XPathNavigator xNavigator = _results.CreateNavigator();

                XPathNavigator xCurrentNode = xNavigator.SelectSingleNode(xpath);

                if (xCurrentNode != null)

                {

                    bool hasNode = false;

                    if (useNextResult)

                        hasNode = xCurrentNode.MoveToNext();

                    else

                        hasNode = xCurrentNode.MoveToPrevious();

                    if (hasNode && 

                        xCurrentNode.LocalName.Equals("Result"))

                    {

                        string resultId = 

                        xCurrentNode.SelectSingleNode("id").Value;

                        string fileUrl = 

                        xCurrentNode.SelectSingleNode("url").Value;

                        url = String.Format("{0}?resultid={1}", 

                           fileUrl, resultId);

                    }

                }

            }

            return url;

        }

        private string GetSearchResultsPageUrl()

        {

            string url = NewsArchivePageUrl;

            string userQuery = 

                NewsArchiveCoreResultsWebPart.GetCachedUserQuery(this.Page);

            if (String.IsNullOrEmpty(userQuery))

            {

                url = String.Format("{0}?resultid={1}", url, _resultId);

            }

            else

            {

                url = String.Format("{0}?{1}&resultid={2}", 

                    url, userQuery, _resultId);

            }

            return url;

        }

    }

}

Note how I use the "resultid" URL parameter to discern between normal navigation to a page and result set navigation between pages. If the resultid parameter is not there, then the navigation controls are hidden. The same goes for when there are no cached results. The "result" link could always be visible for as long as the user's query text is cached.

You can also provide this result set exploration capability for all kinds of pages, not just for a specific page layout, by adding the result set navigation control to your master page(s). The result set <id> and <url> elements are there for all kind of pages stored in your SharePoint solution.

Almost Excluding Specific Search Results in SharePoint 2010

Sometimes you want to hide certain content from being exposed through search in certain SharePoint web-applications, even if the user really has access to the information in the actual content source. A scenario is intranet search that is openly used, but in which you want to prevent accidental information exposure. Think of a group working together on reqruiting, where the HR manager use the search center looking for information - you wouldn't want even excerpts of confidential information to be exposed in the search results.

So you carefully plan your content sources and crawl rules to only index the least possible amount of information. Still, even with crawl rules you will often need to tweak the query scope rules to exclude content at a more fine-grained level, or even add new scopes for providing search-driven content to users. Such configuration typically involves using exclude rules on content types or content sources. This is a story of how SharePoint can throw you a search results curveball, leading to accidental information disclosure.

In this scenario, I had created a new content source JobVault for crawling the HR site-collection in another SharePoint web-application, to be exposed only through a custom shared scope. So I tweaked the rules of the existing scopes such as "All Sites" to exclude the Puzzlepart JobVault content source, and added a new JobReqruiting scope that required the JobVault content source and included the content type JobHired and excluded the content type JobFired.

So no shared scopes defined in the Search Service Application (SSA) included JobFired information, as all scopes either excluded the HR content source or excluded the confidential content type. To my surprise our SharePoint search center would find and expose such pages and documents when searching for "you're fired!!!".

Knowing that the search center by default uses the "All Sites" scope when no specific scope is configured or defined in the keyword query, it was back to the SSA to verify the scope. It was all in order, and doing a property search on Scope:"All Sites" got me the expected results with no confidential data in it. The same result for Scope:"JobReqruiting", no information exposure there either. It looked very much like a best bet, but there where no best bet keywords defined for the site-collection.

The search center culprit was the Top Federated Results web-part in our basic search site, by default showing results from the local search index very much like best bets. That was the same location as defined in the core results web-part, so why this difference?

Looking into the details of the "Local Search Results" federated location, the reason became clear: "This location provides unscoped results from the Local Search index". The keyword here is "unscoped".

The solution is to add the "All Sites" scope to the federated location to ensure that results that you want to hide are also excluded from the federated results web-part. Add it to the "Query Template" and optionally also to the "More Results Link Template" under the "Location Information" section in "Edit Federated Location".

Now the content is hidden when searching. Not through query security trimming, but through query filtering. Forgetting to add the filter somewhere can expose the information, but then only to users that have permission to see the content anyway. The results are still security trimmed, so this no actual information disclosure risk.

Note that this approach is no replacement for real information security; if that is what you need, don't crawl confidential information from an SSA that is exposed through openly available SharePoint search, even on your intranet.