Network Awareness, Office, and SharePoint - Working offline in an online world

Tags: SharePoint, Admin, Configuration

Office 2013 has changed the way it interoperates with SharePoint document management features. Legacy versions of Office relied heavily on DAV as the mechanism to remotely manage the SharePoint document lifecycle. A very common information worker scenario is opening a document from a SharePoint Document Library as read only in an Office client application to review the contents and then deciding to enable editing. With control bars and Backstage view options in the Office clients, this workflow should be seamless by just clicking the appropriate action. If “require checkout” is enabled on the SharePoint Document Library, the “Check Out” option should also be available from the Office client application. In Office 2013, things have changed just enough to disrupt this normal document lifecycle management flow; especially if the workstation has limited connectivity to the internet.

If your Office client is constantly connected to the internet, you normally won’t see a problem managing documents from the Office applications. However, there are a myriad of circumstances that cause disconnected internet connectivity while still maintaining a stable LAN connection to SharePoint. These scenarios usually involve lab setups or development VMs that do not have an active connection to the internet or no internet connection at all. Office 2013 now favors HTTP/HTTPS over DAV and, with the introduction of subscription licensing models and accounts for Office, client applications now need to regularly communicate with public internet services to complete essential functions; especially in SharePoint Server interop situations. Actually, this is not entirely true. Office really only needs to *think* that it has an internet connection to complete subsequent requests whether they are on the internet or local network.

For this post, I am going to consider a Windows 7 workstation setup that is not connected to the internet, does have a stable LAN connection to the SharePoint Servers, and attempts to manage SharePoint documents from Office 2013 clients. In our test case, some essential document management features like check out, check in, discard check out, and version history may not work correctly and the culprit is Network Awareness. Network Awareness is an OS feature that allows network location switching (from, say, a wired to a wireless connection) and provides client applications the ability to check network status from a common API. Everyone is familiar with the yellow exclamation triangle that will display on the network icon in the system tray if a workstation is not connected to the internet (Figure 1). This is an extension of Network Awareness called Network Communication Status Indicator (NCSI – no, not the TV show :) ).

Figure 1 System Tray

Figure 1

Office 2013 relies on NCSI to setup certain application states when clients such as Word and Excel are launched. If Office 2013 detects a “no internet access” state, functions such as SharePoint check out and check in may not work. In a closed network, this can cause problems for development or testing of features that need these document management services. An easy fix would obviously be to connect the workstation to the internet, but we’ll assume this isn’t an available option and discuss how we can restore full fidelity Office document management with SharePoint on a network with no internet access.

 We’ve discussed Network Awareness and NCSI as the key to Office 2013 interoperating with SharePoint correctly, now let’s dive into the details. At the core, NCSI relies on a set of registry entries to probe and verify internet connectivity. The default values are set to check public internet resources to validate an active internet connection. Without access to the internet, NCSI cannot successfully check the default values and the OS reports that there is no internet access. Since the underlying resources are HTTP based, we can trick the OS into thinking that it has internet access by manipulating the registry values.

Disclaimer: full regression testing of essential workstation operations should be conducted before implementing this configuration in a production environment. We will be focusing on Office 2013 and SharePoint LAN document management features. Other required workstations services may need an active internet connection to function properly.
There are 4 steps to configuring an internal NCSI setup:
1.       Ensure active probing is enabled
2.       Host a LAN accessible web site to serve a plain text file for internet connectivity verification
3.       Configure a DNS record for the web site’s host header address
4.       Configure a DNS record to resolve to a known IP address that will not time out
While this list is very straightforward, most available documentation leaves out some essential details, so let’s go over the steps and view a default and sample modified configuration that will enable NCSI to report that the workstation is connected to the internet.
The following guidance involves modifying the registry. If you are not familiar with the registry, please ask a qualified administrator for help!
Step 1
If the following registry key exists:
ensure the EnableActiveProbing (DWORD) value is set to 1.
Step 2
This step allows NCSI to interrogate a web resource, verify the contents of a file, and validate the connection. This is similar to DNS text record verification. Because this step is core to the NCSI process, all of the component parts of the configuration must be correct or NCSI will still report a “no internet access” status.
First, we need a web server that is hosted on our LAN that the workstation can contact. Second, we need to configure a web site with a plain text file that will return a known string.
We won’t go through all of the steps to host the site, but a simple solution is to create a new web site in IIS and add a host header for the site name that you’ll use in DNS; we’ll choose www.ncsi.local for our configuration. After the site is hosted, create a plain text file in the root of the web site and name it “ncsi.txt” The only content inside the file should be “Microsoft NCSI” with no spaces, characters, carriage returns, etc. after the text. You can also place your own string in this file, but we’ll keep the default value of “Microsoft NCSI”.
Step 3
Now that we have our web site that is set to return our text file, we need to add a new zone to DNS for ncsi.local and a record for www.ncsi.local that points to the web site’s host header.
Step 4
This is probably the most misunderstood step, but we simply need a DNS record that resolves to a static IP that will not time out. It’s best to set this as a separate record in the zone we created in step 3, but it could also be the same record that resolves to our web site. Let’s create a separate record with the value dns.ncsi.local and point it to the same web server IP that is hosting our ncsi.txt file.
Now that we understand the generic steps that are required for our internal NCSI configuration, let’s look at the default Windows 7 configuration and then a modified configuration that will allow the OS to report internet connectivity for our workstation.
Default configuration (Figure 2):


Registry location:



 Figure 2 Default NCSI Registry Settings

Figure 2


Modified configuration for our scenario (Figure 3):
 Figure 3 Default NCSI Registry Settings

Figure 3
A couple of points to note in the modified configuration are the ActiveDnsProbeContent and the ActiveDnsProbeHost keys. These are the keys that need to be configured for the DNS record we added in step 4 of our setup. The important part of these values is that the Host needs to resolve to the configured IP AND it cannot timeout. So, simply updating the local HOSTS file will not always work if it references an IP that will timeout. If you cannot add a separate record in DNS for these two keys, you can just use the same values for the host header web site and IP.
Just to reiterate, the ActiveWebProbeContent value is the string that will be returned from the ncsi.txt file specified in the ActiveWebProbePath value. You can substitute the default value for a custom string, but we chose to keep the default.
We can also see the EnableActiveProbing entry in this key. Just like the value in step 1, ensure that this value is set to 1 so active probing is still enabled so our internal NCSI server is used.
That takes us through the why and what of Network Awareness in Windows 7. Usually this won’t be an issue because internet access is ubiquitous. However, if you are working in a lab environment or a closed network, Office 2013 client applications that communicate with SharePoint for document lifecycle operations may not work as expected unless Network Awareness returns a status of “Internet access.” If the environment that is going to use the internal NCSI server includes many workstations, the registry changes outlined above can be packaged into a GPO and automatically pushed out to multiple workstations.

No Comments

Add a Comment