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-09a83588fce3Anonymous
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