Category: Okategoriserade


If you have LACP configured between your Arista-switches (or any other switches) and a Nutanix Cluster, you will run into an issue when using Nutanix Life Cycle Management (LCM).

LCM updates for BIOS, BMC and SATA DOM are currently not supported for Nutanix Clusters that use protocols such as LACP.

If you try to do a full update with LACP active, you will end up with your first node not coming back online and being stuck in maintenance-mode.

The reason behind a node becoming stuck, is because in some of the updates, the nodes boots into the Phoenix ISO and Phoenix does not support LACP at this time.

A work-around is to enable LACP-fallback on your switches. Below is an example with Arista and how quick it is to configure it:

You will need to configure LACP-fallback on all port-channels that are connected to your nodes.

When the upgrade is complete, and the node have booted up, LACP PDUs will be sent out.
LACP will automatically be activated on the port-channel again.

If you have any questions, feel free to email me at or comment down below.


When creating a new Guest Splash Page with either Anonymous, Authenticated or Facebook WiFi the users will encounter an certificate-error after authentication to the Captive Portal.

This is because the users is redirected by standard to or which uses the built-in certificate contained in Aruba Central.

Since you will most likely have external users connecting to your Guest Network you will be required to use a trusted 3rd party CA. I will not cover the steps to retrieve the certificates in this example.

Start by uploading you Server and CA certificate in Aruba Central by going to Global Settings > Certificates. Press + to upload the certificate

After the certificates are uploaded the list should look something like this

To bind the certificates to your Captive Portal go to Wireless Management (Choose the correct group you want to make the changes on) > Security > Certificate Usage. On Captive Portal – select your new Server Certificate and change the Certificate Authority to the CA certificate that you previously uploaded.

As a last step we need to change the Common Name in the Guest Splash Page. Go to Guest Access -> Splash Page and open your created page. Activate “Override Common Name” and enter the FQDN that matches your certificate’s CN.

When this is finished you are good to go, the certificate warning should now be gone!

How to manually crash your VM on a XenServer

Sometimes you need to simulate or provoke a crash on a Virtual Machine to either verify a problem or get a Memory Dump to have a closer look at whats is happening with the Virtual Machine. The thing is, its quite tricky to do that manually. Lucky for you there is a quite simple way to achieve this on a XenServer and I will show every step of the way.

When your Virtual Machine (VM) is at the desired state you should do the following steps:

  1. Find out the VM ID the XenServer has provided the VM, this changes when rebooted so you need to make sure every time you do this, you cannot use the same ID again. First make note of the Virtual Machine UUID, you can find it under “General” for the specific VM.

2. Now we need to find out the ID the XenServer provided for this specific VM. Go the the XenServer Console (the host of the VM) and type the following: list_domains 

As you can see it lists all the VM on this XenServer, and you will also see the ID provided correlated to the UUID. Make sure you have the correct ID and type the following: xen-hvmcrash <ID> (without the brackets). 

Congratulations, You have now successfully crashed the Virtual Machine!

How to handle pinned start menu apps in Windows 10

As I have been working with customizing Windows 10 for a while now, it has never worked against me this much. However, sometimes Windows do have its ways of working against you. With challenges like these you get the opportunity to spend a lot of time coming up with a solution. So this blog post is about my battle with the start menu of Windows 10 Professional. If you are here for the quick solution, skip to the bottom and the TL;DR section.

The Problem:

I have been able to customize the start menu of Windows 10 with ease since version 1511 with the Export / Import-StartLayout cmdlet. But this time I got a request to remove all the pinned apps on the right side of the start menu. A colleague discussed this and he told me he had done a similar solution inside a Citrix Virtual Desktop, and he spent quite the amount of time with this, I thought this would be much easier than it turned out to be. So the requested start menu should at the end look something like this upcoming picture, with the following demands:

  • No pinned apps on the right box or the start menu
  • In the task bar, have Chrome & Explorer pinned. 

This was the requested layout

To begin with, I created an XML file with just Chrome & Explorer pinned in the task bar, and having set the <DefaultLayoutOverride LayoutCustomizationRestrictionType=”OnlySpecifiedGroups”> . My thought was that this would give me a clean start menu, but this was my first failed attempt. The colleague of mine who preciously had a similar issue in a Citrix environment had during his research time come across this post containing a script called “Pin-Apps“. This script contained a Unpin function which turned out to be very helpful. So I started adapting my work after this script. But this is where I came across my second setback. First, I was not able to have this script and the Import-StartLayout-script in the same logon script, nor having one script on startup, and one on login, so I had to think of a way configure this in my isolated lab environment.

Luckily, I’ve been working a lot with OS-deployment, so I created a Task Sequence containing the Import-StartLayout-script, which managed to run successfully together with my login-script containing the Pin-Apps script. But here I came across my third setback, which by far had the most impact and was the one I spent the most time struggling with. For some reason I was not able to remove bloatware, such as Candy Crush, Minecraft etc. The script ran successfully, but every time, the outcome looked like this

Some applications would not be removed

I could not understand why these applications would not be removed. I have had to deal with bloat ware before, but then it was just to remove them with Appx-cmdlets. I checked Get-AppxPackage & Get-AppxProvisionedPackage, and ran Remove-AppxPackage and Remove-AppxProvisionedPackage several times, but these apps were not removable and did not show up until I manually selected them, and they started downloading (as shown on the application in the top right corner on the picture). So apparently they were either links or shortcuts to the Windows Store. This is works if you are using Windows 10 Enterprise. 

This is where I started going deep. The apps were all published in the Windows AppStore, so I started looking for any kind of possibilities, with help from Powershell, to by force download all apps in the Windows Store. I spent a lot of time with this, but without any success. So I had to rethink my plan. There was no way to have the bloat ware-applications to be downloaded by force, there was no way to remove them by removing them with Appx-cmdlets, and there was no way to have a clean start menu with a XML-file. This gave me the idea. If you can’t beat them, join them. There was no way to actively remove all the applications from the start menu of a Windows 10 Professional, but replacing them worked.

The solution:

As I have yet to find any other way of removing the superfluous applications, creating a new XML replacing the start menu with some random default applications was the only successful way for me. To list these applications, go to Shell:AppsFolder or shell:::{4234d49b-0245-)4df3-b780-3893943456e1} in file explorer.

Applications can be found here

I just chose to pin some of the applications which were default on my start menu, that I knew was very much removable, exported these to a new XML which turned out to it look like this:

From here I had to modify the Pin-Apps script to make it more suitable for a Swedish operating system, and added a register key so it would not run more than once on each user. If you want to lock down the right side of the start menu, you just set or create the LockedStartLayout registry key, located under both HKEY_Local_Machine & HKEY_Current_User\Software\Policies\Microsoft\Windows\Explorer, to 1

If you are running another OS language than Swedish or English, to find the verb for unpin, simply save an application name to the variable $appname (as an example I will use Windows Powershell) and run the following part: 

This will give you all the verbs which are applied to this application. In this case “Unpin from Start” is present.

After modifying the necessary bits I added it to a PowerShell logon script GPO with the parameter -UnpinAll, with the .ps1 file located inside the GPO repository, making sure it’s accessible for everyone.



If you are running Windows 10 Professional, you need to replace applications in the start menu before removing them, as a suggestion running in a Task Sequence of some kind setting the default start menu layout and then have a GPO to run the PowerShell script stated above.

If you are running Windows 10 Enterprise, just use the Logon script GPO and you will be fine. If you still have some unwanted applications, run a script removing built-in apps (for example this Invoke-RemoveBuiltinApps )

If you have any questions or thoughts about this post, feel free to email me at

Netscaler: Resolve large http POST packets against AAA protected LB vServers

Recently while working with two customers and setting up load balancing and external access to some of their applications, I’ve encountered issues with large POST packets (either large form submits or file uploads in the web app) stop working when AAA is activated on the load balancing (LB) vServer. In these cases the backend web applications have all been quite old and not exactly well-written coding-wise.

By default when AAA is activated on Netscaler, any large POST packet sent to the LB vServer, and subsequently to the backend, will be split up into two packets with the first one having a Content-Length header value of 0 and the secondary packet containing the correct Content-Length header value and the actual POST body. The backend code in this case is unable to handle the initial 0 length POST packet, and therefore crashes or bugs out before processing the second, real packet. See picture below of the WireShark capture showing the two packets.

IP adress is a SNIP and is the backend server hosting the web application.


The solution is to either have the backend software rewritten to handle above case, or to run a special Netscaler command which will disable the split-post-packet-into-two-packets behaviour. Article contains the relevant info. To resolve this through Netscaler, run the following command in shell on Netscaler, -ys arg1=0 -ys arg2=1 -ys arg3=16 -ys call=”set_sso_post_data_handler”. You have to run the command on all Netscaler nodes (if HA/Cluster) and you also have to put this command line in the file /nsconfig/rc.netscaler, otherwise the change will be lost on the next Netscaler reboot. See for more info regarding the rc.netscaler file.

After the change, you can see how from below picture that only one packet is sent.

One interesting thing to note is that the article doesn’t mention Netscaler version 12.1 as affected, but my guess is that nothing has changes between 12.0 and 12.1 regarding above (ie you still need to run above command to resolve it).

Feel free to email me at, or leave a message here on this blog post, if you have any questions or comments.

Teams in your Multi-user environment done right!

Microsoft Teams is on the rise, more and more businesses is seeing the potential of Teams and want a piece of the action.

Unfortunately Microsoft Teams is not ideally designed to work on a Multi-user environment like Citrix Xenapp or Microsoft Remote Desktop services. It is entirely installed in the users profile, and its quite big. A clean installation of teams is roughly 600 MB and will quickly grow, and you know what that means… You guessed it: Super long logon time, since logging on to the Multi-user environment often means the profile would be downloaded to Session Host before you are properly logged on, the users will not be happy! And on top of that, the latest recommendation in size per Teams installation is 3 GB…

There is however some rumors indicating there will be releasing a business version soon addressing this very issue! But if you are anything like me, and cant simply wait, there is a solution if you are willing to pay a small price, and you will at the same time have access to tons of other great stuff.

FSLogix Profile Container

FSLogix Profile Container is a great product that basically removes the profile size entirely, is an little agent you install on your Session Hosts and configure with an ADMX, you also need a file share with enough space for some big profiles. FSLogix is in the business of so called filter-drivers, what it does is simply put, lying to Windows. For example, when you install a 32-bit application to your 64-bit Windows System, Windows will use its own filter-driver to get it to work, its the same technology, its efficient and simple. In FSLogix case it is lying to the windows about the profiles, Windows thinks its a local profile, it does not know that in fact, the entire profile is contained in a vhd-file, mounted to the server. Because its a virtual disk that attaches to the server, there is only one SMB handle. It will therefor not be a huge load on the network, which you often sees when you for example roam your profiles.

Install Teams

When you have FSLogix Profile Container in place you can now install teams on your environment.  In early October Microsoft released a new version of Teams with some new features when deploying Teams to all the users in an organization, we are going to use parts of that to install Teams on to our environment!


  1. Download the latest version of Teams MSI-file (x64) file here!
  2. If you like to disable Auto-start of Teams use the following install string (otherwise just install without the option):

    This will put an Install file under “C:\Program Files”, and when a user logon it will automatically install Teams to this user.
  3. You do not need to update the MSI to the latest version, Teams will automatically download and install pending updates on the next logon of the user.

There you go, now your users can benefit from the full experience of Teams in your Multi-user environment, with one exception: if you are using Citrix, you have “Skype for Business Optimization Pack” to utilize local client resources for best quality of Skype meetings and calls. There is no support for Teams as of for now. It will soon be available though. With that said, I wouldn’t uninstall Skype for business just yet.

Other Great stuff

As mentioned above, there is a lot of benefits using FSLogix Profile Container. For a great period of time, Citrix User Profile Manager has been the best way to reduce the size of the profiles while still have the most important settings saved in your profile. But this is still just a trade-off, you trade off your caches and settings that impact your profile logon, but at the same time still trying to get the best experience for the user, this will sometimes collide and you have to choose between longer logon time or full functionality of a certain application.

With FSLogix Profile Container you no longer need to worry about large profiles, you don´t need to trade off! There are a lot of applications that saves a ton of settings and files in your profile that you now can install without impacting the user experience, this opens up a great deal of opportunities. You can for example install OneNote with it´s (potentially)  gigantic cache, CAD applications with thousands of files in the user profile and so much more.


If you find this interesting and would like a trial of FSLogix Profile Container to see if this fits your organizations needs, please contact us. It is easily installed and does not require additional servers or infrastructure!


Netscaler: ADFS protected by AAA – How to handle SAML POST requests

A limitation with Netscaler AAA is that it cannot handle FormData sent in a POST request to a Netscaler LB vServer that is protected by a AAA vServer. What happens is that the Form data in the POST will not be included when the user is redirected back to the LB vServer after AAA authentication. This becomes relevant in scenarios where you have a SAML ServiceProvider (SP) that is configured to do a login POST to an SAML IdentityProvider (IDP) and that IDP is protected by Netscaler AAA.

Below is the process flow:
1. User browses to the SAML SP address, which in this scenario is the URL that initiates the SAML logon process
2. The SP gives the user a SAML request and the user’s browser performs a POST against the IDP URL with this SAML Request as the Form data.
3. The address points to a Netscaler LB vServer which is protected by AAA, so when Netscaler sees the incoming GET request above it will redirect the user to for AAA authentication (we assume the user has not authenticated against this AAA vServer this web session).
4. User performs AAA authentication, and is afterwards redirected back to the original URL HOWEVER, the SAML Request Form data is now missing.
5. User will land on and receive an error message, because the ADFS server doesn’t know how to handle a request that doesn’t have any SAML form data.


Important notes:

  • Form Data passed along with a POST to a LB vServer, such as ADFS, that is protected by AAA will be ‘dropped’ when the user is redirected back to the LB vServer after successful AAA authentication. This only applies if the user has not authenticated against the AAA in the current web session (ie the user does not have a NSC_TMAS cookie). We will make use of this later on.
  • Query values included in a POST are not ‘dropped’, so this flaw is limited to Form data only.


The easiest solution is to simply ask the SAML SP to use Redirect instead of POST for the SAML authentication process, but if that is not an option (the SAML SP’s backend code or configuration doesn’t support SAML Redirect) then below is a work-around I’ve been using. Basically what you do is that you store the original SP URL,, in a cookie in the user’s browser and in step 5 the user will be redirected back to this URL again.

Below is the process flow with a work-around implemented for POST:
1. User browses to, which in this scenario is the url that initiates the SAML logon process
2. The SP gives the user a SAML request and the user’s browser performs a POST against the IDP URL with this SAML Request as the Form data.
3. The address points to a Netscaler LB vServer which is protected by AAA, so when Netscaler sees the incoming GET request above it will redirect the user to for AAA authentication.
3b. NEW: When the user is redirected to now, a Rewrite policy will trigger that will create a cookie “ADFSPostCookieURL” for the user, and this cookie will contain the value ““.
4. User performs AAA authentication, and is afterwards redirected back to the original URL
5. NEW: We have a Responder policy on our ADFS LB vServer that checks if the path is “/adfs/ls” and if the cookie “ADFSPostCookieURL” exists, and if both are true then we read the value in cookie “ADFSPostCookieURL” and Redirects the user to that URL.
6. User is redirected back to, which will restart the SAML logon process
7. The SP gives the user a new SAML request and the user’s browser again performs a POST against the IDP URL with this SAML Request as the Form data.
8. A key difference now is that the user already has done AAA authentication this web session and thus has a valid AAA cookie, and won’t be redirected to for authentication. The POST against will therefore happen successfully and the ADFS backend server will see the SAML Form data since that has not been dropped by AAA redirect.
9. Assuming the SAML Request ticket is valid, the ADFS server will give the user a SAML Response ticket and redirect the user to and the user is now logged on to this 3rd party site successfully.



  • Our workaround revolves around storing the original url ( in some way so we can access it later, and requesting a SAML Request ticket twice from our SAML SP because in the second round we will not be bothered by AAA authentication.
  • Above solution is a bit hacky and involves requesting double SAML tickets from the SP, and there are a lot of Redirects involved, but it works well from an end-user perspective and it enables us to support SAML Post in conjunction with AAA.


If you have any questions regarding above solution, or ideas on how to handle above scenario in a better way, please contact me at



Below is the Netscaler configuration:

Troubleshooting XenMobile

EMM systems are complex, error-prone and sensitive to changes from a lot of manufacturers, thus I’ll dedicate this post to just that: techniques for troubleshooting XenMobile. This is not a “I have this problem, what could be the solution”-type post, but I’m rather going to outline some of the more useful tools that you can employ to help solve your problems.

XenMobile Analyzer

Easy to miss, but by far the easiest to use and among the more powerful troubleshooting tools. XM analyzer “simulates” enrolling a device, authentication to both XenMobile and the NetScaler Gateway, browsing to internal URLs with Secure web as well as ShareFile SSO and Secure Mail Auto Discovery. When I’m setting up a new environment or troubleshoot an existing one, I usually start over here since it gives me a nice breakdown of which step fails as well as suggestions for possible fixes. One nice thing is that you can actually schedule reports to run at regular intervals, provided of course you allow enrolls without PIN.

XenMobile Analyzer results

XenMobile Analyzer is available at after logging in with your Citrix account.

XenMobile Connectivity Check

Available in the admin console, under Troubleshooting and Support > Diagnostics > XenMobile Connectivity Checks is this test. It is basically trying to reach other servers necessary for XenMobile to work, and allows you to see whether it works or not. It is a simple way to check if your internal firewalls are blocking something important:

XenMobile Connectivity Checks


Secure Mail Test Tool

If secure mail is what’s acting up for you, there is actually a dedicated test tool available to use. Much like the XenMobile Analyzer, it runs through a lot of tests and checks where it fails, but the Secure Mail Tool runs on your mobile device allowing you to see the other side of the equation. The only trouble with this tool is that you need to wrap it with the MDX tool in order to use it.

Secure Mail Test Tool

You can find more info about the test tool here:

XenMobile Logs

Logs, of course, should hardly need to be mentioned. There are several layers of logs: Debug and User (and admin audit) logs on the appliance, iOS/Android logs on the devices as well as logs from Secure Hub. Make sure to use these to your advantage, and remember that you can change the log levels both when reporting a problem in Secure Hub as well as under Log Settings in the admin UI.

Browsing these logs, however, can be quite a daunting task. I usually start with only the appliance debug log, since you tend to get most of what you need from there. A good start with the debug log would be to check for exceptions, the first row usually gives you the information you need to fix it. Other than that you might need to search the logs for a username or something related to the problems (for example CSR if you’re having trouble enrolling client certificates). If you are able to reproduce the error, make sure you rotate the logs before you reproduce as that’ll leave you with a much shorter log to sift through.

NetScaler AAA log

Most implementations of XenMobile use NetScaler for load balancing and MAM Gateway, and of course a lot of problems could arise here as well. The most basic way to check the NetScaler is to see if it actually accepts your authentication.

To do this, logon to the NetScaler over CLI (PuTTY or other SSH client to the same hostname as the NetScalers, log on with your usual credentials) and run the commands below:

Now you can see the log live, if it’s a well used NetScaler this might be rather busy so you will have to start the logging just before you log on and then stop it afterwards. When you’ve done a logon you’ll get something similar to the image below:

NetScaler aaad.debug log

Here, the top (blurred) rows lists which AD groups the user is in, this is useful to see if the user is actually in that group you connected your delivery policy to. What you want to see is something like the “sending accept to kernel” lines you can see on the screenshot. This means the user has authenticated to the NetScaler properly. Likewise a “sending reject” means the user login was not accepted. If you’re lucky, maybe the user was inputting the wrong password all those times?

NetScaler Policy Hits

XenMobile depends heavily upon session policies for XenMobile to work properly, if these policies doesn’t “hit” for the user you will most certainly see some problems. To check which policies hit when a user logs on, you can check the NetScaler CLI:

Run the commands and then let a user log on and you will get something like the output below.

NetScaler Policy Hits

Do note that this isn’t user specific, all hits occurring during your logging time will be present in the output so you will need to know what you are looking for. If you used the XenMobile Wizard to set up the NetScaler integration, the most important policy you’ll be looking for is the “PL_OS_YOUR_NSGW_IP”-one i highlighted above, as it is the default name for the policy to apply on a log on from a mobile device. You can also see which LDAP policies apply, and if your certificate policies apply as expected.





Also, as a last, more specific tip. If your appliance is failing to boot, just looping on “starting main app”, make sure that the database is available to the appliance. In my experience this is the problem almost every time.

Ny version av Imprivata OneSign

Xenits partner Imprivata har nyligen släppt version 5.2 av sitt marknadsledande system för Single Sign-On och användarautentisering, OneSign. Den nya versionen innehåller en rad förbättringar men även nya funktioner som kan förenkla vardagen för både IT-personal och slutanvändare.

Stöd för Microsoft Windows 10

Agenten som installeras på klienter stödjer nu officiellt Windows 10, vilket låter företag och organisationer att lämna allt mer åldrande uppsättningar baserat på tidigare versioner av Windows.

Stöd för Microsoft Remote Desktop Service

Utöver Citrix XenApp/XenDesktop och VMware Horizon finns det nu stöd även för Microsoft RDS, både som Remote App och som Remote PC. Alltså kan man nu även i en RDS-miljö få skrivbord och applikationer som automatiskt startar upp och följer med användare när de flyttar mellan arbetsstationer.

Självhantering av lösenord för användare

Tidigare har användare själv kunnat återställa sitt lösenord genom att ge svar på tidigare sparade frågor, mycket på samma sätt som när man glömt sitt lösenord på valfri webbsida. Nu har denna funktionalitet utökats med att även kunna visa vilka komplexitetskrav som gäller för nya lösenord samt möjlighet att låsa upp ett låst domänkonto.

Förbättrad licenshantering på tunna klienter

Tunna klienter som använder sig av Imprivata ProveID och Citrix Fast User Switching kan nu konfigureras så de istället för att starta en session automatiskt först väntar på en inloggning från användare. Detta gör att en oanvänd klient inte länge allokerar en Citrixlicens, utan att det sker först när den börjar användas.

Utökad Kerberos-integration

Integrationen med Kerberos har stärkts i denna version, vilket gör att ingen autentisering längre behöver gå via OneSign, utan att förtroende kan upprättas mot alla enheter som är betrodda av Kerberos.

Enrollment Utility

Det finns nu ett gränssnitt för slutanvändaren där de själva kan managera sina kopplade kort, fingeravtryck och sin PIN-kod utan att behöva blanda in support.

Utöver dessa finns en mängd mindre punkter, såsom stöd för fler kortläsare, starkare kryptering, mer flexibla intervall för synkronisering, stöd för Sophos Safeguard Enterprise 7, samt nya versioner av agenter och programvara från Citrix och VMware.


Xenit hjälper gärna till med både uppgraderingar och nyinstallationer av Imprivata OneSign. Vill ni ha mer information eller undrar någonting i övrigt, tveka inte att kontakta oss via e-post eller telefon. Läs även gärna vårt tidigare blogginlägg gällande Imprivata OneSign som ni finner här.