Archives

Archives / 2013 / February
  • SharePoint 2013 and Unified Access Gateway (UAG) 2010 Service Pack 3

    Tags: SharePoint 2013, UAG 2010, Forefront

    Last week the Forefront team finally released Service Pack 3 for Forefront Unified Access Gateway (UAG) 2010. This is a long awaited release for us working with SharePoint 2013 and for those using non-legacy operating systems and browsers. In this post I will show you how to publish SharePoint 2013 Host Named Site Collections through UAG 2010 SP3 and consume the published site using Internet Explorer 10 on Windows 8.

    What’s new in UAG 2010 Service Pack 3

    Before diving into the interesting pieces let’s take a look at some of the new features of Service Pack 3. First of all, to be able to install SP3 you need to have your UAG at SP2 level – SP3 is NOT cumulative.

    The most interesting features in SP3 are support for Windows 8, Windows Phone 8, Windows 8 RT and Internet Explorer 10 (classic and Metro) as client, support for the Office 2013 client and support for SharePoint 2013 as the published application. For SharePoint 2013 the URL Rule Sets has been modified to handle the new types of URL’s and request patterns used in SharePoint 2013, and new endpoint policies are added for SharePoint 2013. If you’re doing an 2010-2013 upgrade, you need to look over any custom URL Rules and policies. There’s also a number of improvements with regards to ADFS publishing.

    Get all the nitty gritty details from the KB article: KB2744025.

    Infrastructure

    Ok, now you know what’s new! Let’s start publish our SharePoint 2013 sites through UAG. First of all before even installing UAG you need to think about your infrastructure, network, DNS and certificates (there it is again – certificates!). The picture below shows my demo environment. As you can see I have a UAG 2010 SP3 server with dual NIC’s (actually it have three – but we can safely ignore that). One NIC is connected to the Corporate Network and the other one to the External Network.

    Demo infrastructure

    DNS

    Before starting our publishing and SharePoint 2013 configuration we need to plan our DNS namespace. We need at least one publically available (that is a real) domain name. For this demo I will use three:

    • trunk.corp.local – this will be used for my UAG Trunk Portal
    • sp.corp.local – this will be a SharePoint 2013 site
    • teams.sp.corp.local – this will be another SharePoint 2013 site

    In order to make it efficient for the end-users I do prefer to have alignment of URL’s internally and externally. In this case it means that I have the second two domains above registered in the internal DNS as well. There is no need to register the Portal/Trunk domain internally.

    Certificates

    When publishing sensitive stuff such as SharePoint content you most likely would like to use HTTP over SSL, HTTPS, to encrypt the data flying throughout the internet. This is not only a good option to do externally, you should do it internally as well – even more now with SharePoint 2013 and the authorization flow over HTTP. Utilizing HTTPS internally also gives you the benefit of URL alignment for internal and external users and you don’t have to worry about sending an unreachable link. And we don’t have to do SSL termination.

    Certificate requestWhat you essentially need is one or two certificates – one from a trusted root authority to use on the UAG server and one for SharePoint, which can be a local CA issued certificate. You could use the same though. You should use wildcard certs or SAN certificates here – so in the end it comes down to manageability and costs of certificates.

    In this sample I use one certificate, issued by my local CA. So any external clients, not joined to the domain will get a certification error (unless they have the CA root cert as a trusted root authority – which my external demo machine have). Specifically the Office clients have issues with not trusted certs.

    The certificate is a SAN certificate covering sp.corp.local, trunk.corp.local and *.sp.corp.local. The certificate is installed on the SharePoint 2013 machine and on the UAG 2010 machine.

    SharePoint with HTTPS

    Before starting the UAG configuration let’s take a quick look at how the SharePoint 2013 farm is configured. In the SharePoint farm there is one Web Application using SSL on port 443. This Web Application is used to host Host Named Site Collections. This installation has two; sp.corp.local and teams.corp.local.

    Web Applications

    Install and update UAG 2010 to SP3

    Installing Unified Access Gateway 2010 and patch it to Service Pack 3 is quite easy. But first of all – UAG 2010 SP3 does not support Windows Server 2012, so you have to dust off your old Windows Server 2008 R2 DVD’s and get used to that annoying Start button in the lower left corner.

    Before inserting the DVD though, make sure that the OS is patched – yea, this machine should be a secure box and should have all the latest security hotfixes etc. Secondly make sure that you have the two required NIC’s wired in. Third – configure the NIC’s. If you’re uncertain on how to configure the NIC’s there is a good TechNet Wiki article called “Recommended Network Adapter Configuration for Forefront UAG” that is highly recommended as a starting point.

    InstallationOnce all that is set, insert the DVD and follow the wizard to install UAG. If your DVD is a UAG SP1 you need to apply the following patches, in this order, to get up on Service Pack 3.

    1. UAG Service Pack 1 Update 1
    2. TMG Service Pack 2
    3. UAG Service Pack 2
    4. UAG Service Pack 3

    Once that is done a reboot is not out of order. Especially if you fiddled with the NIC’s and haven’t rebooted since.

     

    Initial UAG configuration

    Once you’re up on UAG Service Pack 3 it’s time to do the first time configuration of UAG. It’s a three step wizard that automatically starts when you fire up the UAG Management console the first time – and you can’t bypass it.

    The first step is to connect UAG to your different NIC’s. As I said you need two of them – one for the internal network and one for the external network. In the Network Configuration Wizard (Step 1 in the UAG Getting Started Wizard) you have to choose which adapter to connect to the UAG Internal and External zone respectively. A good practice is to name your network adapters (in Windows) and give them describing names so they are not called just “Local Area Connection 1” and “Local Area Connection 2” – very easy to make stupid mistakes then…

    The image below shows how I connected my “Corporate Network” NIC to the Internal UAG zone and the “External Network” to the External UAG zone. The machine have a third NIC – which I leave unassigned in this case.

    UAG NIC Settings

    Click Next when you’re done and finish the wizard. Step 2 in the Getting Started Wizard let’s you specify the UAG topology – leave it as as a single server and finish the wizard. Step 3 is the obligatory – do you want Windows Update and do you want to send usage data to Microsoft – I’ll leave it up to you to figure out the settings here.

    Note: you can always get back to the Getting Started Wizard by choosing Admin > Getting Started in the UAG Management app.

    Now all is set to start publishing some applications.

    Creating a UAG Trunk

    All applications in UAG are published in Trunks. A trunk consists of a portal and one or more applications. Each trunk have a set of shared settings between the different published applications – such as a public host name, certificate, URL Rules, endpoint policies, authentication and authorization settings etc.

    Since we would like to publish an HTTPS SharePoint 2013 application we start with creating a new Trunk under the “HTTPS Connections” node in the UAG Management App.

    New Trunk...

    This will start yet another wizard (YAW). In Step 1 choose to create a Portal trunk. In Step 2 we need to specify the name, public host name and IP of the trunk.

    Trunk Settings

    Step 3 is used to configure how the end-user will authenticate. Click Add to select (at least) one Authentication Server. If you don’t have any servers in the server list you need to add one. You have a lot of options here – but in most cases you will add an Active Directory server and connect it to your forest. You also need a service account for this – that needs permissions to retrieve user information and change password.

    In Step 4 it’s time to select the external certificate. Hopefully you followed the instructions and have already registered the certificate on the UAG box. Choose the appropriate certificate and click next. If you’re like me and using a dummy domain (corp.local) you will get a warning here – it’s safe to ignore, we’re only writing a blog post.

    Certificate Settings

    The fifth step allows you to select what kind of endpoint protection you would like to use. Choose between UAG access policies or NAP. Choose UAG and continue to step 6, where you choose the endpoint policies – keep the default ones and continue. Then review your settings and click finish.

    That’s it, you now have a trunk. All you now need to do is to save and then activate your new configuration. This is done through the cog wheel button in the management console.

    Activation

    You should now be able to test if you can access the trunk from a remote machine. The first time you access the trunk URL you will be asked to download and install the Forefront UAG client components. Depending on your configuration you will have limited access to your applications unless you install it. These components does a number of client security validations and they are also responsible for cleaning up your machine when you log out. Once logged in you should see an “empty” portal saying “No applications defined”.

    If you don’t see anything like this or get errors here – it’s most likely related to certificates. Make sure that you have a correctly issued certificate registered with the Trunk. Also check the certificate chain and make sure that all the certs in the chain are trusted.

    Add an application to the trunk

    Now the time has come to publish our SharePoint 2013 Site Collection. In the Trunk you created under Applications click the Add button. YAW! In Step 1 you specify what kind of application you want to publish. You will find SharePoint 2013 under Web – it’s called “Microsoft Office(!) SharePoint Server 2013”.

    SharePoint 2013 Application

    Click next, give the application a name. In Step 3 leave all the endpoint policies as-is – you could easily spend a day fiddling with these if you have the time or need. In the fourth step choose to publish an Application Server. You should choose this if you have one server or a SharePoint farm behind some kind of load balancer. Step 5 is where you configure the actual SharePoint 2013 application. Add the name of your internal SharePoint 2013 site and specify the public host name. In my case my SharePoint 2013 site is published using HTTPS internally so I need to specify HTTPS/443 here – no SSL Termination.

    Web Servers

    Step 6 – Authentication. Choose an authentication server (use the same as you created and used for the Trunk). Here you also specify how rich clients authenticate with your application – in my case I choose to use both Rich Client integration and a Office Forms Based AuthN.

    In the seventh step you configure how the application appears in the portal and in the eight and last step you can configure which users actually have access to your application, but just leave the default settings for now – that is everyone who can log in can also access the application (note, that this doesn’t mean they bypass any security in SharePoint).

    Once you’re done with the wizard you should have two applications listed in your trunk – the portal and your newly added SharePoint site:

    Applications

    Now save and activate your new configuration.

    Take it for a test-drive…

    Close down your browsers, if you did test to log in to the Trunk earlier, and browse to the public portal URL once again. If you don’t see your application – log out of the portal and log in again.

    You should see something like this:

    The Portal

    Now, click on the application link and see how beautifully your SharePoint 2013 site is published through UAG. Test how you can drag and drop documents, open them in Office clients, edit lists in Quick Edit mode and work just perfectly!

    Woohoooo....

    Publishing the second SharePoint 2013 Site Collection is exactly the same – you add a new Application to the trunk and follow the wizard.

    Summary

    In this post I showed you how to install, patch and configure Forefront Unified Access Gateway (UAG) 2010 Service Pack 3 to be able to publish SharePoint 2013 Web Applications and Site Collections. It’s a pretty straightforward approach but involves some crucial steps. If you previously published SharePoint 2010 applications using UAG you noticed that there is no difference with regards to setting it up. The difference are in the details, specifically in the URL rules applied and a new set of policies.

  • SharePoint 2013: SharePoint Health Score and Throttling deep dive

    Tags: SharePoint 2013

    The SharePoint Health Score was introduced in SharePoint 2010 and plays an even more important role in SharePoint 2013. The Health Score determines the health of a SharePoint server/web application on a scale from 0 to 10, where 0 is the most healthy state. SharePoint automatically starts throttling request once the Health Score is to high. The Health Score is can be calculated using many parameters, such as memory usage, concurrent requests etc. In this post I will give you some details on how the Health Score works, how you can troubleshoot it and how you can use it and how you can configure it.

    Note: this article contains some registry changes that never ever should be done on a production server, unless told by Microsoft support...or whatever...

    What is the Health Score?

    Let’s start with some background facts. Stop whining, I know plenty of peeps have already blogged about it but I think it is good to have all the facts in this same blog post.

    The Health Score is as an integer between 0 and 10, where 0 represents a really good health of the server, or rather Web Application, and 10 is where you do not want to be. SharePoint continuously calculates the Health Score and for each and every request the Health Score is sent as an HTTP Response Header, called X-SharePointHealthScore.

    The SharePoint Health Score in action!

    This Health Score is used by (or at least should be used by) client applications to determine the health of the web application and then use it to make a decision on whether it should stop hammering the web application or not. If the Health Score reaches up to 10, SharePoint itself will start to throttle requests (which we’ll talk about in just a bit).

    Worth noticing here is even though this article is written for SharePoint 2013, most of it is valid on SharePoint 2010 as well.

    How the SharePoint Health Score is calculated

    So, how does SharePoint calculate this Health Score? When a SharePoint Web Application spins up, internally a new thread is created (you can see it in debuggers with the name SPPerformanceInspector). This thread regularly reads performance counters and calculates the Health Score. Each time it calculates the Health Score it will log this to the Trace Logs (Category=Http Throttling, Level=Verbose):

    The current health score for web application is X

    ULS shows you the current health score

    Performance Counters

    The Health Score is calculated from a set of Performance Counters. By default SharePoint 2013 (and SharePoint 2010) uses two performance counters for this:

    • Memory/Available MBytes
    • ASP.NET/Requests Current

    You can easily retrieve these performance counters by using the following cmdlet:

    Get-SPWebApplicationHttpThrottlingMonitor http://app.contoso.com

    You can also use the Set-SPWebApplicationHttpThrottlingMonitor cmdlet to modify the current monitors.

    Buckets, what is that!?

    When running the cmdlet above, to retrieve the performance counters used to calculate the Health Score, you should have noticed that each associated performance counter has a property called AssociatedHealthScoreCalculator.

    Buckets of what?

    This is an array of values, or a set of Buckets, that SharePoint uses to calculate the Health Score. There are 10 buckets in each of those (you can have fewer). Each bucket represents a Health Score value and corresponds to a lower limit of the performance counter. For instance if you have 24 current ASP.NET requests – you will have a Health Score of 4 and if you have less than 200 MB of RAM available you will have a Health Score of 6. The Health Score of the Web Application is equal to the largest Health Score of all measured performance counters.

    Adding your own ,monitor

    To add your own performance counters to monitor you need to use the API. Here’s a sample on how to add the CPU usage as a monitored object. You should not add this one into any production environment, but it can be used in testing scenarios when you would like to see what happens when the Health Score is high.

    $throttle  = (Get-SPWebApplication http://app.contoso.com).HttpThrottleSettings
    $throttle.AddPerformanceMonitor("Processor", "% Processor Time", "_Total", 10, $true)
    $throttle.Update()

    This will create a new monitor for the Web Application that checks the processor time on the machine. It will only have one bucket. So if the processor time is larger than 10 it will yield a Health Score of 10.

    Refresh Interval

    The Health Scores are by default updated every 5 seconds. You can get (or set) this setting by looking at the HttpThrottlingSettings of a Web Application like this:

    $throttle = (Get-SPWebApplication http://app.contoso.com).HttpThrottleSettings
    $throttle.RefreshInterval

    To avoid having spikes in performance counters creating high Health Scores, the actual value is calculated from an average of a number of samples, by default 12 samples. This can be configured using the NumberOfSamples property on the HttpThrottleSettings.

    How SharePoint uses the Health Score

    Now you know a little bit more on how the SharePoint Health Score is calculated. So what is it used for then? SharePoint internally uses it for mainly two reasons; HTTP throttling and for the Request Management Service.

    HTTP Throttling

    Whenever the SharePoint Health Score reaches the value of 10, SharePoint 2013 starts its throttling mechanism to protect the servers. As soon as the Health Score is below 10, the servers stops the throttling. The actual throttling is divided into two steps – the first and second stage. After receiving a Health Score of 10 and SharePoint enters throttling it will start with the first stage and requests will start to be throttled. After one minute of throttling the throttling enters the second stage and starts throttling even more. What’s being throttled in the different stages depends on a set of throttling classifiers. Out of the box (in SharePoint 2013) there is only one classifier used – which checks if the current request is a search crawler. This classifier starts throttling request directly in the first stage – all other requests are handled as usual. When the throttling enter the second stage all requests will be throttled (default, if you have any custom classifiers some requests might be allowed).

    The Server is busy now. Try again later

    Throttled requests are met with the Error message above: “The Server is busy now. Try again later”, and the HTTP Response: “503 Service Unavailable”.

    When entering the second stage of throttling, you will see the following lines in the ULS logs. The logs also includes the “Excessive” counters.

    Ouch, we're hogging the machine!

    To the Server is Busy response SharePoint also adds two Response Headers; one called “Retry-After” which contains a numeric value which should be taken as an indication (by clients) when a retry operation should be done (it’s always has the same value as the Health Score refresh interval) , and a second one “SharePointError” which always has the value of “2”.

    By the way, if you notice the nice little error icon in the Busy error. That image is not throttled, why? Well, I can tell you…there’s actually an exclusion for that specific image with regards to resource throttling. Requests to that image will never be throttled.

    HTTP Throttling of POST Requests?

    There’s this myth out there that POST and PUT requests are never throttled. Well, that is to good to be true! My tests and reverse engineering skills shows that all requests are throttled in SharePoint 2013 (I would be glad to be proven wrong :). Fortunately Office 2010 and later has the “Upload Center” which will retry any save operations and eventually succeed once throttling has stopped.

    But, using one of the built-in classifiers we can actually make sure that our precious documents are saved regardless of HTTP Throttling, and this is how this is achieved.

    $classifier = New-Object Microsoft.SharePoint.Utilities.SPHttpUserAgentAndMethodClassifier 
        -Args "","POST","HttpMethodMatch", "Never"
    $throttle = (Get-SPWebApplication http://app.contoso.com).HttpThrottleSettings
    $throttle.AddThrottleClassifier($classifier)
    $throttle.Update()

    First of all we create a new classifier of the type SPHttpUserAgentAndMethodClassifier, when creating that object we pass in “POST” as HTTP method, make sure it’s using the HttpMethodMatch method to match the method :), and finally we tell it to never throttle these requests. We add this classifier object to the throttle settings of the web application and badabing, POST operations are not longer throttled.

    Turning off HTTP Throttling

    On or Off?Ok, so you’re fed up with this throttling and want to turn it off. It’s an easy operation and you can do it from Central Administration or from PowerShell. In PowerShell just update the PerformThrottle property of the HttpThrottleSettings of the web application. And in Central Administration you select the Web Application for which you want to turn off throttling, then select General Settings > Resource Throttling, then at the bottom of the dialog you will find HTTP Request Monitoring and Throttling.

    HTTP Throttling and automagic garbage collection

    The HTTP Throttling is actually a quite smart implementation, and internally tries to fix your machine if throttling occurs. One thing that is important here is if you start fiddling with the different performance counters used for calculating the Health Score, make sure that you do not remove the monitor that monitors memory usage. That plays a special role in the throttling scenario. If that specific monitor is considered an “Excessive” monitor, which means that it has an Health Score of 10, it will actually force a Garbage Collection.

    Request Management

    SharePoint 2013 introduced the new Request Management Service, which is used to “redirect” requests to specific servers based on rules and/or health. When using health based rules, it is the SharePoint Health Score that is used to determine the health of a server. Whenever a machine receives a request it will update the Health Score in the Request Management service, which makes the Health Based Request Management a very efficient way to “load balance” the requests for optimal performance.

    For more information about Request Management read Spencer Harbars series about it.

    How to use the SharePoint Health Score

    Whenever you’re building a client that interacts with SharePoint 2013, for instance a SharePoint App, a Windows 8 app or a Windows Phone app, then you should strongly consider always take the Health Score in consideration. You will receive the X-SharePointHealthScore response header for each and every CSOM, REST or web service call to SharePoint. If the value is 10 (and SharePoint starts throttling) then you will most likely not be able to get data. If your application is constantly polling SharePoint for information, perhaps you should increase the delays between your calls when the Health Score raises above a predetermined number.

    Andrew Connell has a small code sample on how to leverage this in a Silverlight app.

    The SPPerformanceInspector

    You could also use the Health Score in traditional SharePoint Farm solutions (timer jobs, or other long running or resource consuming operations) using the SPPerformanceInspector object. Here’s a quick sample how you can show the data in a Web Part:

    SPPerformanceInspector pi = 
        SPPerformanceInspector.GetInspector(SPContext.Current.Site.WebApplication);
    
    this.Controls.Add(new LiteralControl(
        String.Format("Current Health Score: {0}<br/>", pi.HealthScore)));
    this.Controls.Add(new LiteralControl( 
        String.Format("Is throttling: {0}", pi.IsInThrottling())));

    This Web Part retrieves the performance inspector object and then prints out the current Health Score for the current Web Application on the current machine. Also this Web Part will print out if throttling is currently going on (which you never should see anyways, since you’re throttled!).

    How to debug the SharePoint Health Score

    To wrap this little post up I will give you two great debugging tips – they both involve editing the registry (you’re warned!). First of all if you’re building a remote application that communicates with SharePoint and you want to test how it behaves at different Health Scores. Then there’s a neat trick to give a server a constant Health Score value. You do this by adding a new DWORD key called ServerHealthScore to the HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\WSS hive and then do an IISRESET. You can give this key any value from 0 to 10 and the Response Header will always show that value. It will not invoke throttling though.

    ServerHealthScore regkey hack!

    It will of course log a warning in the ULS telling you how bad this really is:

    You've been warned!

    The second tip is a cool debugging feature, and its also a small regkey hack. In the same hive as above create a new DWORD key called DebugThrottle and give it the value of 1.

    DebugThrottle regkey hack!

    Once again you need to do an IISRESET. After that you can browse to any page and then append debugthrottle to the address, for instance: http://site.contoso.com/debugthrottle. This will give you a sweet looking dashboard with all the details you need about the health of the server/web application. You can see the monitors and their Health Score history, the throttling stage, your classifiers etc.

    Classy design!

    Summary

    There you have it! All you need to know about the SharePoint Health Score and HTTP Throttling. As you can see it’s a really nice feature if used correctly – by you, by third party vendors (I’m pretty sure 99% of the vendors do not care about this though) and by SharePoint itself. Just one final word of warning – if you’re fiddling with monitors and classifiers make sure that you thoroughly test them, it’s really easy to get things funked up here…

  • Office Web Apps 2013: Securing your WAC farm

    Tags: WAC Server, Office Web Apps, SharePoint 2013, Security

    With this new wave of SharePoint, the Office Web Apps Server (WAC – I don’t like the OWA acronym, that’s something else in my opinion) is its own server product, implementing the WOPI client protocol, which allows a client to retrieve documents from SharePoint on the behalf of the user. Documents will flow from the WOPI servers (SharePoint, Lync, Exchange etc.) to the Office Web Apps Server – this means that potentially confidential information will be transferred from the SharePoint environment and stored/cached on another server. This could result in unnecessary information leakage and compromise the enterprise security.

    In this post I will walk through a number of steps that you can do to properly secure your Office Web Apps 2013 farms. And you should seriously consider and implement most of these methods.

    Note: this post focuses on the Office Web Apps Server and not a WOPI client in general (but if you’re building your own you should consider security as well!).

    The WOPI protocol specification and security

    Note: I will not cover how WOPI clients and servers implements the server to server authentication and authorization.

    WAC runs as Local System

    To start with it is very important to know that the Office Web Apps Server 2013 runs as the Local System and Network Service on the machine it is installed on. There is no service account or anything! This means that you cannot protect your systems using dedicated accounts etc., like you do with SharePoint, SQL and other applications.

    The images below shows the Office Web Apps Windows Service, which runs as LocalSystem.

    Local System

    And this image shows some of the applications pools in the IIS on an Office Web Apps machine.

    Network Service

    The advantage of using these local accounts is that it makes installation and configuration easier. But it is very important that you are aware of this configuration.

    SSL is a requirement!

    Exposing the Office Web Apps Server over HTTPS should be a requirement in my opinion. There is no reason not to. Having it on HTTP will only cause trouble for you; for instance if your SharePoint uses https you will not be able to render the iFrame containing the document (aka WOPI Frame) since you’re not allowed to show http content in an https environment. But first and foremost you’re sending data in clear text.

    So what about SharePoint on HTTP then? Well, if you’re using SharePoint 2013 you should seriously consider running that over HTTPS as well – that IS a best practice. SharePoint 2013 leverages several technologies that sends tokens and credentials over the wire, OAuth for instance, so in order to have a secure environment make sure you use HTTPS for SharePoint as well. If you are running SharePoint on HTTP you must fiddle with the security settings in SharePoint to allow OAuth over HTTP – and this is not a good thing.

    Certificates are king!

    Any WAC farm running on SSL must have a certificate for the HTTPS endpoint. You can use self-signed, issue certificates using a Domain CA or buy a certificate. When you’re creating the WAC farm, using New-OfficeWebAppsFarm, you can/should specify the certificate.

    For any SharePoint, WAC and even SQL installations nowadays certificates are more and more important. If you’re on the verge of deploying these in your organization you should consider deploying a Domain CA – which is not a lightweight task.

    Securing the communication using IPSec

    If you for some reason do not run HTTPS on SharePoint and/or WAC you could consider implementing IPSec. Unfortunately there is no button in the Control Panel that says “Use IPSec”. This is something that requires careful planning and testing. So going SSL might be an easier way. But consider the scenario where you have an internet facing web site which leverages WAC and using the HTTP protocol – then you should consider using IPSec for the communication between SharePoint and Office Web Apps Server.

    Firewall considerations and requirements

    When setting up your Office Web Apps Farm you should also configure the firewall for the WAC machines. Office Web Apps uses four different ports. It uses 80 and 443 for HTTP and HTTPS, that’s used by the end-users and the WOPI Server/Client communication. Internally Office Web Apps uses port 809 (HTTP) and 810(HTTPS) for communication between the WAC machines. I’ve only seen 809 in use, which is the default. There is no way (I’ve found at least, but internally WAC has a switch to use port 810) to configure WAC to use port 810 and if you do find a way, it’s likely unsupported. The things sent over the wire using the admin channel (809) is mainly health and configuration information for the WAC farm, but it would be nice to be able to secure this channel as well (IPSec!).

    When installing WAC the Windows firewall is configured to allow incoming TCP connections on port 80, 443 and 809.

    WAC Windows Firewall Rule

    As always it is a good practice to evaluate these default rules and if you’re not using port 80, disable that port. For port 809 it might also be a good practice to make sure that it only allows incoming connections if they are secure (i.e. implement IPsec).

    Even more secure...

    Preventing rogue machines

    So far we’ve been talking about how to secure information being transmitted from and to the Office Web Apps farm. Let’s take a look at Office Web Apps farm security from another angle. Joining a new WAC machine to an Office Web Apps Farm can be quite easy. The only thing that you need is local administrator access on the WAC machine that is the master (the Get-OfficeWebAppsMachine gives you the master machine). Depending on how you’re having your (virtual) metal hosted this might be a problem, too many sysadmins have to much permissions out there. If you have this access then you can easily join a rogue machine to the WAC farm and take control over it, without the users/client knowing anything about it.

    There are a couple of methods you can and should use to protect the WAC farm. And the error messages below can also be a good troubleshooting reference…

    Master Machine Local Administrator

    If the account trying to create the new WAC machine does not have local admin access on the machine specified when joining the WAC farm you will simply get an “Access is denied”.

    New-OfficeWebAppsMachine : Access is denied

    As a side note; if you’re not running the cmdlet using elevated privileges you will get an “You must be authenticated as a machine administrator in order to manage Office Web Apps Server”.

    Using the Firewall

    I already mentioned the firewall. If the machine joining the WAC farm cannot access the HTTP 809 channel the New-OfficeWebAppsMachine will throw a “The destination is unreachable error”.

    The destination is unreachable error

    This is a fairly easy way to protect the farm, but if the user has local admin access on the master machine it can easily be circumvented.

    Certificate permissions

    If you’re using a domain CA, make sure that you protect the private key using ACL’s, or if you’re buying a certificate make sure to store the certificate private key in a secure location. If you’ve specified a certificate when the Office Web Apps farm was created, which you should have, then the user cannot join the new machine – regardless of local machine admin, since the user cannot install the certificate locally. The error message shown is “Office Web Apps was unable to find the specified certificate”.

    Office Web Apps was unable to find the specified certificate

    Using an Organizational Unit in Active Directory

    The way that Microsoft recommends to secure your WAC farm is to have a dedicated OU in Active Directory where the computer accounts for the WAC farm is located. When joining a new machine to the farm the cmdlet verifies that the account is in the OU specified by the WAC configuration. If it’s not then you’ll see the “The current machine is not a member of the FarmOU”.

    The current machine is not a member of the FarmOU

    The Farm OU is specified when creating a new WAC farm or using the Set-OfficeWebAppsFarm/ cmdlet. The only caveat with this OU is that it has to be a top level OU in Active Directory. Creating that OU in your or your customers AD might cause some headache, but if you want to use the FarmOU as protection method for your farm it has to be this way. That’s the way it is designed!

    Also having all the WAC servers in a OU gives you other benefits; such as using Group Policies to control the WAC servers.

    Limit the WOPI Server and host access

    Now we’ve seen how we protect the farm from rogue machines and data tampering. Another issue with the WAC farm in it’s default configuration is that any WOPI Server can use it. Might not be a big problem for most of the internal installations, but what if you’ve designed a WAC farm and someone with a huge SharePoint collaboration implementation connects to your WAC farm. It can sure bring it down. Or if you’re exposing your Office Web Apps farm on the internet anyone on the internet can potentially use it.

    For this purpose there’s a cmdlet called New-OfficeWebAppsHost. This cmdlet allows you to specify host names that will be accepted by the WAC farm. The cmdlet interprets any domain with a wildcard. For instance the following cmdlet will allow all WOPI Servers on contoso.com (www.contoso.com, extranet.contoso.com etc.) to contact the WAC farm:

    Set-OfficeWebAppsHost -Domain "contoso.com"

    Do not forget to do this!!

    Summary

    You’ve seen quite a few ways how to protect your WAC farm from information leakage, rogue machines, undesired excessive usage etc. Using HTTPS and certificates together with a dedicated OU in Active Directory will give you the most secured WAC Farm. Hopefully you also understand a bit more on how Office Web Apps Server works internally. It’s a magnificent and simple server product, but it should be handled with care. 

About Wictor...

Wictor Wilén is a Director and SharePoint Architect working at Connecta AB. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for four consecutive years.

And a word from our sponsors...

SharePoint 2010 Web Parts in Action