Web service

Citrix Self-Service Session Reset Tool Process Flows

by

***Updated for the release of v1.6.

There are eight (8) main process flows for the how the Citrix Self-Service Session Reset Tool works:

  1. User Opens Web Page Process Flow
  2. Get Sessions Process Flow
  3. Logoff Sessions Process Flow
  4. Disconnect Sessions Process Flow
  5. Restart Machines and Forcefully Restart Machines Process Flow
  6. Hide Sessions and Unhide Sessions Process Flow
  7. Get Processes Process Flow
  8. Terminate Processes Process Flow

Each flow is documented and visually represented below.

Read more

Citrix Self-Service Session Reset Tool

by

***Please refer to my article on Development Planning for the Citrix Self-Service Session Reset Tool to learn about what updates and new features are being worked on.

***If using a release less than v1.9, please refer to the release history below to understand the new features, enhancements and fixes now included.

This tool has been labelled as a game changer for any Citrix customer. It’s proven time and time again that it has a huge impact on reducing the burden on the Service Desk and Operations Teams by empowering users to get themselves back up and running in the shortest possible time.

No matter how stable your Citrix platform is, one of the biggest challenges for any Citrix customer is being able to reduce Service Desk calls and user downtime by empowering users with the ability to clear their own sessions, or recover them by terminating rogue processes. Several free scripts and a paid for tool are available, but none of them really achieve the best outcome. Some of them still require users to run a “Citrix session”, which they often can not do because the broker may be trying to reconnect them back to a stuck, hung, broken session or unhealthy host. When this happens they get into an endless loop of failure and get very frustrated. This can impact brand reputation and user satisfaction, leaving users with a poor felt experience. Some have even implemented a separate Citrix Environment to run these scripts from. In my opinion this is as waste of resources and an overhead for management. It still doesn’t always work due to Citrix Workspace (Receiver) reconnection issues and is often over complicating it for users.

My goals were to:

  • Create a tool that is easy to use, even for users that struggle with technology.
  • Create a tool that enables users to not only get themselves back up and running in the shortest possible time, but also reduces the reliance on Service Desk and even second level support teams.
  • Create a tool that does not rely on any ICA/HDX connectivity to a Citrix platform. This was extremely important!
  • Create a tool that would allow support for multiple Citrix Virtual Apps and Desktops (CVAD aka XenApp and XenDesktop) Sites.
  • Create a tool that works across trusted Domains.
  • Create a tool that works across the IT and OT landscape.
  • Create a tool that can easily be extended/expanded for other use cases.
  • Create a tool that’s modular so that other brokers such as VMware Horizon and Leostream can easily be added.
  • Create API’s with a Web front-end.
  • Create a tool that can be used to develop a microapp.
  • Create a tool that can easily be called by any scripting language such as PowerShell and Python.
  • Create a tool that can be enhanced, debugged and supported by others.
  • Create a tool for the community, because I love doing that!

Read more

Installing, Configuring, Securing and Using MDT Webservices – Part 3

by

In Part 1 we walked through the installation and configuration of Deployment Webservices.

In Part 2 we walked through securing the Webservice.

In this part I will demonstrate how to use the Webservice via a PowerShell script to securely move a computer object during the operating system deployment (OSD) task sequence using Microsoft Deployment Toolkit (MDT).

To achieve the end result we need to:

  • Create some deployment share rules in MDT (CustomSettings.ini)
  • Add two “Run PowerShell Script” tasks to the Task Sequence
  • Download and place the PowerShell Script into the deployment share Scripts folder

Read more

Installing, Configuring, Securing and Using MDT Webservices – Part 2

by

In Part 1 we walked through the installation and configuration of Deployment Webservices. In this part we will focus on securing the Webservice.

There are five (5) main areas that I focus on to lock down the Webservice, and I’ll include two (2) optional areas for consideration:

  1. Use Request Filtering, which is basically what the old URL Scan morphed into from IIS 7 (Windows 2008) and above. Request Filtering gives a tighter level of control over the settings and where they are applied than URL Scan ever did.
  2. Authentication – Disable anonymous authentication. That should be a no-brainer!
  3. Authorization Rules – Only allow specific users access.
  4. Changing the authenticatedUserOverride serverRuntime setting to UseWorkerProcessUser. IIS 7.5 (Windows 2008 R2) and above allows us to configure IIS so that the worker process identity is used for accessing resources, such as the file system, whilst the authenticated user is only used for authorization purposes. This means that you only need to set NTFS permissions for the worker process identity.
  5. Setting NTFS Permissions on the DeploymentWebservice folder for the worker process identity.
  6. Optionally, you can also exclude some of the higher risk AD Functions.
  7. Optionally, you can also SSL enable the site with a certificate.

Read more

Installing, Configuring, Securing and Using MDT Webservices – Part 1

by

This will be a three part article on installing, configuring, securing and using Maik Koster’s Deployment Webservice.

I’m a massive fan of Microsoft Deployment Toolkit (MDT) and use it for all customer deployments that don’t already have a modern and/or mature deployment model.

The Deployment Webservice is required to complement MDT for two main reasons:

  1. The Active Directory Net Framework classes are NOT supported in WinPE, which means that WinPE does not support the use of ADSI. So when you rebuild a device/image, you are unable to easily automate moving of the computer object to a build/staging OU before the Domain Join process. This is important when there is an existing object in Active Directory because you don’t want it to join to an existing object where unwanted Group Policy Objects may apply, that may in-turn break the build process, or at least make it unreliable.
  2. The MDT task sequence does not run as a Domain User with permissions to easily achieve this task. Whilst in MDT you can run a script as a different user, I don’t like using those configuration fields, as it means my task sequences end up being hard coded with credentials. I wanted a far more flexible approach so that I could pass it existing variables or derive them directly from the Task Sequence variables.

Read more