So this is a blogpost based upon a session I had at Citrix User Group here in Norway this week, which is essentially about can Office365 work in conjunction with Citrix ? and what do we need to think about ?
There are multiple stuff we need to think / worry about. Might seem a bit negative, but that is not the idea just being realistic
So this blogpost will cover the following subjects
- Federation and sync
- Optimizing Office ProPlus for VDI/RDS
- Office ProPlus optimal delivery
- Shared Computer Support
- Skype for Buisness
So what is the main issue with using Citrix and Office365? The Distance….
This is the headline for a blogpost on Citrix blogs
So how to fix this when we have our clients on one side, the infrastructure in another and the Office365 in a different region ? Seperated with long miles and still try to deliver the best experience for the end-user
First of is, do we need to have federation or just plain password sync in place? Using password sync is easy and simple to setup and does not require any extra infrastructure.
NOTE: Now since I am above average interested in Netscaler I wanted to include another sentence here, for those that don’t know is that Netscaler with AAA can in essence replace ADFS since Netscaler now supports SAML iDP. Some important issues to note is that Netscaler does not support • Single Logout profile; • Identity Provider Discovery profile from the SAML profiles. We can also use Netscaler Unified Gateway with SSO to Office365 with SAML. The setup guide can be found here
Using ADFS gives alot of advantages that password hash does not.
- True SSO (While password hash gives Same Sign-on)
- If we have Audit policies in place
- Disabled users get locked out immidietly instead of 3 hours wait time until the Azure AD connect syng engine starts replicating, and 5 minutes for password changes.
- If we have on-premises two-factor authentication we can most likely integrate it with ADFS but not if we have only password hash sync
- Other security policies, like time of the day restrictions and so on.
- Some licensing stuff requires federation
So to sum it up, please use federation
Secondly, using the Office suite from Office365 uses something called Click-to-run, which is kinda an app-v wrapped Office package from Microsoft, which allows for easy updates from Microsoft directly instead of dabbling with the MSI installer.
In order to customize this installer we need to use the Office deployment toolkit which basically allows us to customize the deployment using an XML file. We can then use Group Policy to manage the specific applications and how they behave. Another thing to think about is using Target Version group policy to manage which specific build we want to be on so we don’t have a new build each time Microsoft rolls-out a new version, because from experience I can tell that some new builds include new bugs –> https://msandbu.wordpress.com/2015/03/09/trouble-with-office365-shared-computer-support-on-february-and-december-builds/
Office365 versions found here: http://support2.microsoft.com/gp/office-2013-365-update?
Another thing that if we want to use Office365 in conjunction with RDS/XenApp we need to have atleast E3/E4 plans which include that support. This is done using something called Shared Computer support, which allows us to install and run Office Click-to-run from a terminal server.
<Display Level="None" AcceptEULA="True" /> <Property Name="SharedComputerLicensing" Value="1" />
Another issue with this is that when a user starts an office app for the first time he/she needs to authenticate once, then a token will be stored locally on the %localappdata%\Microsoft\Office\15.0\Licensing folder, and will expire within a couple of days if the user is not active on the terminalserver. Think about it, if we have a XenApp farm with many servers that might be the case and if a user is redirected to another server he/she will need to authenticate again. If the user is going against one server, the token will automatically refresh.
NOTE: This requires Internet access to work.
And important to remember that the Shared Computer support token is bound to the machine, so we cannot roam that token around computers.
But a nice thing is that if we have ADFS setup, we can setup Office365 to automatically activate against Office365. This just requires that we configure some Office365 Group Policies to make that happen.
This is part of the ADMX template from Office2013
Add the ADFS domain site to trusted sites on Internet Explorer and define this settings as well
Which allows us to basically resolve the token issue with Shared Computer Support
We also need to add the ADFS site to Trusted Sites in Internet Explorer and specify that within the esecurity settings of trusted sites that usernames and password be automatically be used within.
Since we can’t use MKS or PVS for use with Office365 ProPlus, we need to use shared computer support. On VDI instances users can use their regular
We can also use the Office deployment toolkit to generate a package which we can deployment instead (https://support.microsoft.com/en-us/kb/2915745) we can also use this only resource to create deployment files for us.
The use of App-V package allows for easier deployment and allows our IT guys to customize which applications that should be available to the end users. This also allows to deploy it using SCS or using the Configuration Manager Connector from Citrix. This also gives us the possbility to central manage updates and specify which applications should be visible to the endusers. And also allows us to control updates in a better fashion.
Another important thing to remember is that Office is quite fond of GPU, so if hardware acceleration is enabled and there is there is GPU present, it will to Software GPU which means that the CPU has more to do.
So by all means no gpu, disable hardware acceleration (NOTE that even thou by default it is disabled if no GPU is present) but some features might not function properly)
More info here –> https://shawnbass.com/psa-software-gpu-can-reduce-your-virtual-desktop-scalability/
And another thing is that by default if we want to deploy Office within a VDI enviroment we should do some tuning on our Windows 10 machines. Did you know that by default in a VDI enviroment a Windows client OS behaves like it is communicating with Internet based devices all the time. Meaning that it is tuning the TCP accordingly. We have an PowerShell cmdlet called Get-NetTCPsetting which defines the TCP stack for a Windows client. For Windows Servers they are running the profile called datacenter, while clients even thou inside the datacenter are running using Internet. So in a VDI enviroment we can define the datacenter profile for our client computers using the cmdlet Set-NetTCPProfile
This also changes the TCP congestion algoritm to DCTCP instead of CTCP.
Microsoft also has an application called Office365 client analyzer, which can give us a baseline to see how our network is against Office365, such as DNS, Latency to Office365 and such. And DNS is quite important in Office365 because Microsoft uses proximity based load balancing and if your DNS server is located elsewhere then your clients you might be sent in the wrong direction. The client analyzer can give you that information.
Now for some reason (which will also appear later) we need to use the tradisional Office package (which is using volum license, which is not based upon a user license) we need to setup either using KMS or MAK.
So important to remember that Citrix supports use of KMS with PVS and MCS (While MAK is not supported)
So in regards to Skype for Buisness what options do we have in order to deliver a good user experience for it ? We have four options that I want to explore upon.
- VDI plugin
- HDX realtime
- Local app access
- HDX Optimization Pack
Now the issue with the first one (which is a Microsoft plugin is that it does not support Office365, it requires on-premises Lync/Skype) another issue that you cannot use VDI plugin and optimization pack at the same time, so if users are using VDI plugin and you want to switch to optimization pack you need to remove the VDI plugin
HDX realtime works with most endpoints, since its basically running everyone directly on the server/vdi so the issue here is that we get no server offloading. So if we have 100 users running a video conference we might have a issue If the two other options are not available try to setup HDX realtime using audio over UDP for better audio performance.
Local App access might be a viable option, which in essence means that a local application will be dragged into the receiver session, but this requires that the enduser has Lync/Skype installed. This also requires platinum licenses so not everyone has that + at it only supports Windows endpoints…
The last and most important piece is the HDX optimization pack which allows the use of server offloading using HDX media engine on the end user device
And the optimization pack supports Office365 with federated user and cloud only users. It also supports the latest clients (Skype for buisness) and can work in conjunction with Netscaler Gateway and Lync edge server for on-premises deployments. So means that we can get Mac/Linux/Windows users using server offloading, great…
Only issue is that it does not support Office Click-to-run and that it requires Enterprise licensing
Another important pieze is to remember that it requires the Lync UI (Not the Skype UI) because that is uses the Lync SDK.
Now for more of the this part, we also have Outlook. Which for many is quite the headache…. and that is most because of the OST files that is dropped in the %localappdata% folder for each user. Office ProPlus has a setting called fast access which means that Outlook will in most cases try to contact Office365 directly, but if the latency is becoming to high, the connection will drop and it will go and search trough the OST files.
(We could however buy ExpressRoute from Microsoft which would give us low-latency connections directly to their datacenters, but this is only suiteable for LARGER enterprises, since it costs HIGH amounts of $$)
But this is for the larger enterprises which allows them to overcome the basic limitations of TCP stack which allow for limited amount of external connection to about 4000 connections at the same time.
Because Microsoft recommands that in a online scenario that the clients does not have more then 110 MS latency to Office365, and in my case I have about 60 – 70 MS latency. If we combine that with some packet loss or adjusted MTU well you get the picture
Using Outlook Online mode, we should have a MAX latency of 110 MS above that will decline the user experience. Another thing is that using online mode disables instant search. We can use the exchange traffic excel calculator from Microsoft to calculate the amount of bandwidth requirements.
In order to adjust this we can set something called cached mode, meaning that Outlook will store email for the last months (this is customizable) in the OST file, and the rest will need to be fetched online from Office365) We can also define that all users should go online always and have nothing cached locally but this might not give a good user experience.
This allows us to have a smaller OST file, but still have a good user experience. Now the last part is that we can’t have these OST files stored locally on each terminalserver, so we need to have good profile management solution in place in order to handle this properly. Important to note that Microsoft supports having OST files on a network share, IF! there is adequate bandwidth and low latency… and only if there is one OST file
NOTE: We can use other alternatives such as FSLogix, Unidesk to fix the Profile management in a better way.
Important to remember that Microsoft will not help troubleshoot if you are having performance related issues.
Some rule of thumbs, do some calculations!
Heavy online users generate about 20 MBps of network traffic (using online mode onoly)
Heave online users /with 3 months cached data will generate about 10 MBps of network traffic (This is only the bandwidth going directly to Office365 and does not count for the traffic that is going atainst the OST file locally)
And important to have Office Outlook over SP1 which gives MAPI over HTTP, instead of RCP over HTTP which does not consume that much bandwidth.
But we can use Profile Management to manage our OST files from a network share. Remember that the OST files in most cases are 50-80% larger then the mailbox itself because of the way it stores content, and it requires a huge deal of lantecy, plus that file locking is an issue. So for instnace if we are using Lync on one XenApp server which uses Outlook to save conversation, and then opens another connection and open Outlook there we might get errors because of the OST file locking yay!
In regardsa to OneDrive try to exclude that from XA/XD users, since the sync engine basically doesnt work very well and now that each user has 1 TB of storagee space, it will flood the storage quicker then anything else, if users are allowed to use it.
You can remove it from the Office365 configuration by adding this in the xml file
<ExcludeApp ID=»Groove» />
So anyhow, I had a great time at Citrix User Group, this year! and yet again I was part of the team that won the challenge!