Publishing SharePoint mobile for Windows Phone 7

Preface

Publishing SharePoint mobile for Windows Phone 7 with UAG is easy. However, it is possible to achieve similar results using TMG (or even other 3rd party reverse proxies)

In this post we will provide the high-level topology architecture used in order to access published SharePoint sites from WP7. This post also provides a step-by step demonstration using Forefront TMG.

High-Level Topology Architecture

The following is a flow description, explaining the roles of each of the above components:

1. John is the owner of a WP7 device and has just received an email from Lesley. The mail contains a link to Lesley’s page in the corporate SharePoint site. Note: the link sent by Lesley is the internal SharePoint URL, which is not publically accessible.

2. John clicks the link embedded within Lesley’s mail.

3. By clicking the link, John’s phone actually calls the SignURL.asp page that is hosted on the web server and is published by UAG. The full URL is: “https://<Reverse Proxy Address>/internalsite/SignUrl.asp?signURL=http://internal_server_name”.

4. The web server then replies to John’s phone with an echo of the SharePoint internal site name (copying the input parameter to the reply).

5. The reverse-proxy (UAG) intercepts the web server’s response and translates the SharePoint internal site name to an external name, one that John can access publically.

6. John’s phone is then redirected to Lesley’s external SharePoint site.

About SignURL.asp

This page is responsible for echoing the name of the internal server, so that it can be translated by the reverse-proxy, and thus informing the WP7 device of the public address of the internal server. This page must be placed under a virtual directory called internalsite (\internalsite\) because currently, WP7 makes a specific request to “https://<Reverse Proxy Address>/internalsite/SignUrl.asp” .

The request must also include a parameter named signURL in which the WP7 device sends the internal server name. An example of the full request made to the reverse proxy is: “https://<Reverse Proxy Address>/internalsite/SignUrl.asp?signURL=http://internal_server_name”.

The following is an example of a typical signurl.asp:

<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>

<%

Response.AddHeader "Cache-Control", "no-cache"

Response.AddHeader "Expires", "-1"

url = Server.HTMLEncode(Request.QueryString("SignURL"))

'the request does not contain url parameter

if Len (url) = 0 then

Response.status = 400

Response.write "SignURL parameter is not defined."

'url is not legal

elseif InStr(lcase(url),"http:\\") <> 0 and InStr(lcase(url),"https:\\") <> 0 then

Response.status = 400

Response.write "Invalid SignURL parameter structure."

else

Response.write url

end if

%>

This page relies on the reverse proxy engine to replace the internal_server_name with the proper public address name it was given, and let the WP7 device use this for the next request.

Other considerations and enhancements for hosting signURL.asp

It is possible to implement the signURL.asp in different languages, such as CGI (Common Gateway Interface). However, it is important to maintain identical functionality. When implementing the page in a different language, you must maintain the same URI, including the “asp” extension.

It is possible to host this page on a cluster, for fault tolerance and redundancy considerations.

It is possible to host this page on an existing web server. The virtual directory “internalsite” can be used to differentiate between the different websites.

Important things to note regarding the reverse-proxy and the client (WP7)

Reverse proxy:

1. The reverse proxy must publish the web server with the SignUrl.asp page using HTTPS without authentication.

2. The reverse proxy must be able to perform link translation for requests to the SignUrl.asp page.

3. The reverse proxy must be configured so it is able to translate the internal SharePoint URL to the external SharePoint URL

Client (WP7):

1. Windows Phone must be configured in the following way:

o The Forefront UAG address must be the reverse proxy address, which corresponds to the published web server with the SignUrl.asp page.

2. The client should trust the SSL certificate which is used to publish the SignUrl.asp page.

Using TMG instead of UAG

The following is a step-by-step configuration example, illustrating how TMG can replace UAG in the role of a reverse-proxy

1) Configure the Web listener for HTTPS traffic without authentication.

2) Publishing rule for SignUrl.asp page, which uses this web listener and has link translation enabled.

3) Publishing rule for SharePoint site with link translation enabled.

Notes:

· It is not required to publish the SharePoint site on the TMG machine. Instead, you can define a global mapping or local mapping for the SignUrl rule, which translates the internal SharePoint site name to its external name.

Comments

• Anonymous
  January 01, 2003
  "Microsoft is killing the TMG"--- Is that true? social.technet.microsoft.com/.../c9fed466-0636-46fa-b599-09a83588fce3

• Anonymous
  January 01, 2003
  FYI: technet.microsoft.com/.../gg274302.aspx To allow mobile devices to use SharePoint Workspace Mobile you must publish a Microsoft SharePoint Server 2010 application through Forefront Unified Access Gateway (UAG). technet.microsoft.com/.../ff393835.aspx Forefront UAG is the only VPN server that is supported by Microsoft Office Mobile on Windows Phone 7 and Windows Phone 6.5. For more information about how to configure Forefront UAG to support Microsoft Office Mobile, see Configure Forefront UAG for SharePoint Workspace Mobile, later in this article.

• Anonymous
  June 11, 2012
  Hi, this doesn´t work with Windows Phone 7 and OneNote Notes? If we do this, you see an anonymous request on TMG and the phone jumps up in folder structure and didn´t open the notice book. Anybody else have this problem? Thank you. Michael