However I would like to share one post that you will find very interesting as why Microsoft is re-architecting ?. I leave you here with a good read and good bye.

https://blogs.technet.com/b/systemcenter/archive/2015/06/08/why-microsoft-decided-to-re-architect-everything-when-competitors-wouldn-t.aspx  

Enable Two Factor Authentication on your Microsoft account and this is how you set it up for the first time :

https://windows.microsoft.com/en-GB/windows/two-step-verification-faq 

Once done then to generate 2nd factor token , windows store has an app to do this , so consider this as your key fob:

Authenticator App is available in Windows Store:

https://www.windowsphone.com/en-us/store/app/authenticator/021dd79f-0598-e011-986b-78e7d1fa76f8  

finally you will logon using username \ password as usual to Microsoft account however a second page will now ask for token , this is where you have to use Authenticator App on the phone and type that code and there you go. This app is continueously in sync with Microsoft Network time servers and keep generating random tokens 24x7.

Feel free to suggest this family and friends, its quite good.

Windows Mobile Phone site has documented few steps about setting up the Office hub for external users but it doesn't tell you anything more that that. You can review this here:

 https://www.windowsphone.com/en-us/how-to/wp7/office/use-office-sharepoint-workspace-mobile 

However in terms of setting up things on the UAG side of things , what you need to do it is setup typical SharePoint publishing app or use your existing one and ensure that on SharePoint 2010 server you do setup correct AAM configuration to consume the zones that user through UAG when using external URL will hit and SharePoint should be redirected to the correct site. I am not going to document all this as there is a lot fo resource now available but from old days three blog posts on setting up AAM on SharePoint and configuring UAG server with correct host name are still my favourite that were written by my colleague Meir in the days of IAG. its a three part tutorial that is a great reference to sort AAM configuration and setting up DNS and UAG SharePoint settings. Please review the following blog posts for this :

Part 1:

https://blogs.technet.com/b/edgeaccessblog/archive/2008/10/12/publishing-sharepoint-with-iag-2007-part-1-what-is-sharepoint-aam-and-why-do-we-need-it.aspx

Part 2:

https://blogs.technet.com/b/edgeaccessblog/archive/2008/10/13/publishing-sharepoint-with-iag-2007-part-2-common-questions.aspx

Part 3:

https://blogs.technet.com/b/edgeaccessblog/archive/2008/10/13/publishing-sharepoint-with-iag-2007-part-3-sharepoint-topologies.aspx

and finally TechNet UAG SharePoint publishing guide should you need more details:

https://technet.microsoft.com/en-us/library/dd857299

Once External user is now able to access SharePoint correctly from Mobile Phone browser and you are able to launch the office document hosted on SharePoint office library  , it means SharePoint AAM and UAG SharePoint application is configured correctly.

Now moving forward we intend to open  the office document directly from Windows Mobile 7 Office hub feature. In Windows Phone 7  in Office hub --> click the UAG tab and put the SharePoint portal AAM name that you have setup on UAG <documentation link provided above> .

On the backend ensure that SharePoint 2010 is setup for Forms based authentication.

Please review SharePoint 2010 documentation on how to do this:

First go through this article just to understand as what you are about to do on SharePoint side of things :

 https://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx

Now the better way of achieving this is:

https://blogs.msdn.com/b/sridhara/archive/2010/01/07/setting-up-fba-claims-in-sharepoint-2010-with-active-directory-membership-provider.aspx

Once SharePoint is setup correctly with FBA , Office hub will work correctly through UAG 2010.

The challenge is if user is having multiple profiles on his mobile device while synchronizing his inbox , it is possible that user might come across inbox of other profile that he is not supposed to view...!.  Users might notice different behaviours , some times users see inbox of the second profile while phone is synchronizing using Exchange active sync , at times users have experienced that once synchronization is done they start getting view of the correct inbox but question is why this is happening ?.

This problem is down to the behaviour of session cookie handling by UAG. It depends on various factors as well for instance if there is a load balancer sitting in front of UAG , it could fiddle with session cookies. I have also seen issues when load balancer configured to do "connection pooling" causes funny behaviours , so better test Connection Pooling before enabling it when LB is siting in front of UAG.

Anyways in UAG SP2 release we fixed the session cookie behaviour to make each session unique. For this specific scenario explained above and with UAG SP2 installed you need to make a registry tweak as shown below , that will allow users having multiple profiles on the same mobile device (IOS or Windows phone ) synchronize to there respective mailbox without any session overlap problems for Exchange Active Sync.

The fix is as follows:

1. On the UAG server, please create a new DWORD registry value, as follows:

// This should cause UAG to not base its session management on the UAG session cookie ("NLSession…"), for ExchangeActiveSync.

SOFTWARE\WhaleCom\e-Gap\Von\UrlFilter\SuppressEASSessionCookie

2. Assign it a value of ‘1’

3. Activate the UAG configuration

Once this registry is in place on top of UAG SP2 the above scenario will work.

"Your computer can't connect to the remote computer because the Remote Desktop Gateway server reached its maximum allowed connections. Try reconnecting later or contact your network administrator for assistance."

I started dubgging this and ended up working with Remote Desktop Gateway support in Microsoft and we found a bug in this features implementation. The great news is we have a hotfix available now and KB2649422 is available to install on UAG server if you run in to the above mentioned issue.

For more details please review the Knowledge base article:

https://support.microsoft.com/kb/2649422

hope this helps.

The following error is logged on the UAG server:

Description:
The user "Alfa\uagservice", on client computer "127.0.0.1", did not meet resource
authorization policy requirements and was therefore not authorized to resource
"10.1.2.194". The following error occurred: "23002".

I took some ETL tracing on Windows 2008 R2 and then based on it I took a memory dump and debugged this when this configuration was in action in memory of the server and set break point when policy function was called. I worked with Remote Desktop Escalation Engineer in Microsoft support (a colleague basically) to help through RD part of the code and noticed RAP function call made to RDG was expecting a policy to be applied using the IP address. When I looked at UAG configuration, I realized that due to not having this documented we are all just giving in FQDN of the RD Farm servers.

Remote Access Policy failure will occur if Session Broker is sitting behind the UAG (RDG) because RAP needs the IP address to communicate to the farm.

To resolve this issue here is the configuration change thats required:

When you publish RemoteApps / RemoteDesktop please add RD Connection broker on UAG server wizard or under Server Settings tab on the application (RemoteApp or RemoteDesktop), you need to add Connection broker name on top of the list and then session hosts FQDN plus their IP addresses as well in this stage of the wizard or Server tab of the applications.

 <<Screenshot below>>

With this configuration in place UAG 2010/SP1 should be able to work across RD Farm if session broker is sitting behind the UAG (which is also the RDP Gateway).

Hope this helps.

In simple previously Citirx was first installing the Citirx web client and then authenitcating the end user accessing XenApp landing page, now with WI 5.4 they first do authN and then install the client component, which makes sense from WI point fo view as they do have security reservations.

Debugging showed that we are getting in 302 redirect loop at "/Citrix/.*/auth/silentDetection.aspx. I reversed the flow and narrowed down to problem where certain cookies that are signed by UAG are not being interpreted by XenApp. So what I had to do is to write a custom SRA file as follows:

In SRA file <WhlFiltSecureRemote_HTTPS.xml> under cookie handling tag this is what you need to do:

<?xml version="1.0"?>

<WHLFILTSECUREREMOTE ver="2.2">
<COOKIES_HANDLING>
  <SERVER>
   <SERVER_NAME mask="">.*</SERVER_NAME>
   <Set-Cookie remove="">
    <NAME>WINGSession</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
   <Set-Cookie remove="">
    <NAME>WIUser</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
   <Set-Cookie remove="">
    <NAME>WIClientInfo</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
  </SERVER>
  <SERVER>
                          <SERVER_NAME mask="">.*</SERVER_NAME>
               <Set-Cookie>
                    <NAME>WINGSession</NAME>
                    <Secure remove="true"/>
               </Set-Cookie>
               <Set-Cookie>
                     <NAME>WIUser</NAME>
                     <Secure remove="true"/>
               </Set-Cookie>
                <Set-Cookie>
                     <NAME>WINGDevice</NAME>
                     <Secure remove="true"/>
               </Set-Cookie>
                <Set-Cookie>
                      <NAME>WIAuthId</NAME>
                      <Secure remove="true"/>
               </Set-Cookie>
               <Set-Cookie>
                      <NAME>WIClientInfo</NAME>
                       <Secure remove="true"/>
                </Set-Cookie>
  </SERVER>
  </COOKIES_HANDLING>
</WHLFILTSECUREREMOTE>

===============

The above will fix the looping problem of WI 5.4 through UAG.

You need to copy this file to ...\Microsoft Forefront Unified Access Gateway\Von\Conf\Websites\<your trunk name> \Conf\CustomUpdate

PS: Dont copy /Paste this from here as it might break the XML Syntax and to test that out once you write this file just load it in Internet Explorer to see if its healthy and not broken. Also feel free to tweak the files as you would like as its a very generic configuration I am sharing here.

I would also suggest to use the WhiFiltAppWrap_HTTPS.xml to avoid other known Citirx issues in previous WI 5.x builts. You need to copy this file along with the other in same location <...\Microsoft Forefront Unified Access Gateway\Von\Conf\Websites\<your trunk name> \Conf\CustomUpdate> .

===============

<?xml version="1.0"?>

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">

 <MANIPULATION>
<MANIPULATION_PER_APPLICATION>
    <APPLICATION_TYPE>CitrixXenApp5</APPLICATION_TYPE>
    <!-- citrix 4.5 fix client cookies issue -->
    <DATA_CHANGE ee="1">
    <URL case_sensitive="false">/Citrix/.*/auth/silentDetection.aspx</URL>
    <!-- check if RWS is secured or not -->
    <SAR>
        <SEARCH encoding="base64">ZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</SEARCH>
        <REPLACE encoding="base64">
ICAgICAgICAgICAgICAgICAgICB3aGxJc1NlY3VyZSA9ICJGQUxTRSI7DQogICAgICAgICAgZnVuY3Rpb24gY2hlY2tXSExSV1MoKQ0KICAgICAgICAgIHsNCiAgICAgICAgICB2YXIgd2hsVVJMID0gbG9jYXRpb24uaHJlZjsNCiAgICAgICAgICBpbmRleDEgPSB3aGxVUkwuaW5kZXhPZigiLy8iKTsNCiAgICAgICAgICBpbmRleDIgPSB3aGxVUkwuaW5kZXhPZigiLyIsaW5kZXgxKzIpOw0KICAgICAgICAgIGluZGV4MyA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDIrMSk7DQogICAgICAgICAgaW5kZXg0ID0gd2hsVVJMLmluZGV4T2YoIi8iLGluZGV4MysxKTsNCiAgICAgICAgICAvL2dldCB0aGUgd2hsIGluZGljYXRvciBmb3IgYSBzZWN1cmUvIG5vbiBzZWN1cmUgUldTDQogICAgICAgICAgd2hsVVJMID0gd2hsVVJMLnN1YnN0cmluZyhpbmRleDQtMSxpbmRleDQpOw0KICAgICAgICAgIC8vbWVhbnMgdGhlIFJXUyBpcyBzZWN1cmVkDQogICAgICAgICAgaWYgKHdobFVSTCA9PSAiMSIpd2hsSXNTZWN1cmUgPSAiVFJVRSI7DQogICAgICAgICAgfQ0KICAgICAgICAgIGNoZWNrV0hMUldTKCk7DQogICAgICAgICAgZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==
        </REPLACE>
      </SAR>
      <!-- setting isSecure to false -->
      <SAR>
        <SEARCH encoding="base64">dmFyIGlzU2VjdXJlID0gKGxvY2F0aW9uLnByb3RvY29sLnRvTG93ZXJDYXNlKCkgPT0gJ2h0dHBzOicpOw==</SEARCH>
        <REPLACE encoding="base64">dmFyIGlzU2VjdXJlID0gd2hsSXNTZWN1cmU7</REPLACE>
      </SAR>
      <!-- remove secure setting when creating cookie on client machine -->
      <SAR>
        <SEARCH encoding="base64">aWYgKHdpbmRvdy5sb2NhdGlvbi5wcm90b2NvbC50b0xvd2VyQ2FzZSgpID09ICJodHRwczoiKQ==</SEARCH>
        <REPLACE encoding="base64">aWYgKHdobElzU2VjdXJlPT0iVFJVRSIp</REPLACE>
      </SAR>
      <!-- disable the line: "cookie = cookie + "; path=" -->
      <!-- https://support.citrix.com/article/CTX117597 -->
      <SAR>
        <SEARCH encoding="base64">Y29va2llID0gY29va2llICsgIjsgcGF0aD0=</SEARCH>
        <REPLACE encoding="base64">Ly8gY29va2llID0gY29va2llICsgIjsgcGF0aD0=</REPLACE>
      </SAR>
    </DATA_CHANGE>
  </MANIPULATION_PER_APPLICATION>
 </MANIPULATION>

</APP_WRAP>

==============

Once both the WhlFiltSecureRemote_HTTPS.xml and WhlFiltAppWrap_HTTPS.xml files are in place WI 5.4 should work fine. Please note if you already have custom files in place for other apps on your trunk then carefully merge this in those exisiting files.

PS: Some of the users seeing the Cookie Session error once redirect problem is resolved. So the solution for that one is just adding two more cookies to the above proposed SRA file so here we go:

<WHLFILTSECUREREMOTE ver="2.2">
<COOKIES_HANDLING>
  <SERVER>
   <SERVER_NAME mask="">.*</SERVER_NAME>
   <Set-Cookie remove="">
    <NAME>WINGSession</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
   <Set-Cookie remove="">
    <NAME>WIUser</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
   <Set-Cookie remove="">
    <NAME>WIClientInfo</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
   <Set-Cookie remove="">
    <NAME>WIAuthId</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
   <Set-Cookie remove="">
    <NAME>WINGDevice</NAME>
    <Path remove="true">/Citrix/XenApp</Path>
   </Set-Cookie>
  </SERVER>
 <SERVER>

         <SERVER_NAME mask="">.*</SERVER_NAME>
               <Set-Cookie>
                    <NAME>WINGSession</NAME>
                    <Secure remove="true"/>
               </Set-Cookie>
               <Set-Cookie>
                     <NAME>WIUser</NAME>
                     <Secure remove="true"/>
               </Set-Cookie>
                <Set-Cookie>
                     <NAME>WINGDevice</NAME>
                     <Secure remove="true"/>
               </Set-Cookie>
                <Set-Cookie>
                      <NAME>WIAuthId</NAME>
                      <Secure remove="true"/>
               </Set-Cookie>
               <Set-Cookie>
                      <NAME>WIClientInfo</NAME>
                       <Secure remove="true"/>
                </Set-Cookie>
  </SERVER>
  </COOKIES_HANDLING>

Hope this helps.

 PS: this post is written considering a very generic and almost XenApp default configuraiton through UAG. Feel free to tweak the XML files as per your requirements.

For custom Paths issue review Ben's blog as he got a nice post up there https://blogs.technet.com/b/ben/archive/2011/10/05/issues-with-citrix-5-4.aspx

https://blogs.technet.com/b/tomshinder/archive/2010/08/03/how-to-configure-uag-to-publish-your-private-certificate-revocation-list.aspx

So the problem scenario was as follows:

When you publish RDP tunnel application on UAG portal and on template if you change the Tunnel application setting from port forwarding to Socket forwarding , mstsc fails to launch.

UAG out of box RDP Windows XP/Vista Tunnel application template looks like :

  <exec exe="mstsc.exe -w:%HRes% -h:%VRes% -v:%leadserver%" flags="4" param="" use-with-lsp="only" />

While working with this issue in lab I noticed that when we enable SF on RDP tunnel App the application calls mstsc.exe from %systemRoot%\system32 directory and that is causing a problem. It should be called from %SystemRoot%\SysWoW64 directory as we need to launch 32 bit app .

 If you go to %SystemRoot%\system32 and rename mstsc.exe to mstsc.exe.bak or any random extension and then go close the browser and launch this app again after new logon session, it will launch the tunnel successfully because this will now invoke mstsc.exe from SysWoW64 directory.

 Note:

 To rename the mstsc in system32 you might be prompted for permissions:

 Browse to %SystemRoot%\System32

Right click mstsc.exe and choose Properties

Go to the Security tab

Click Advanced

Go to the Owner tab

Click Edit

From the “Change owner to:” list, choose your user name

Click OK

Go to the Permissions tab

Click Change Permissions…

Click Add

Enter your user name and click OK

Tick the box in the Allow column for Full control

Click OK

Click OK

A Windows Security warning will come up; click Yes to proceed

Click OK

So to me it looks like the two instances of mstsc.exe onWindows 7 x64 , one in %SytemRoot%\system32 and second in %SytemRoot%\sysWoW64 is causing the confusion.

Another approach is to publish a generic enhanced application for 64 bit clients which launches the MSTSC  from %SystemRoot%\SysWoW64

Being in support I have been asked this question as how to enable split tunneling in windows 7 using SSTP through UAG portal. Ofcourse UAG product group clearly states that SSTP is non split tunnelling bydefault so it means split tunnelling is not possible from UAG portal.Anyhow I got a case few weeks ago where one of our premier customer had this requirement to enable split tunnelling using SSTP. I knew the answer that its not possible and not supported, however I started fiddling with UAG SSTP in my lab environment. Digging through Source code and testing various scenarios I managed to find the way to enable split tunnel. Let me walk you through this failrly simple but unsupported configuration. Let me also set your expectations first, this is a client side solution , its not elegant so you need to have a mechanism of dropping the modified dialer file on all windows 7 machines that would be launching SSTP split tunnel through portal and this is not a supported solution from Microsoft UAG support. if you are happy with all disclaimers then lets proceed further :).

Steps to configure SSTP Split tunneling :

1-  Sstp.pbk is part of \InternalSite\Win32ActiveX\WhlClntProxy.cab. so once you deploy UAG client components on Windows 7 endpoint this pbk file gets dropped with them. Now extract the SSTP.pbk file from UAG client components.

2- Click on properties and click the Networking button and select Networking tab:

3- Click TCP/IPV4 and hit properties button:

4- Click the Advance button and under IPSettings tab uncheck the "Use default gateway on remote network" option:

5- now copy this SSTP.pbk file back to UAG client components directory on windows 7 machine.

6- Launch the SSTP application from UAG portal now and check your routing table .

hope this helps ;-)