The Boot Time components of a PVS server

December 27, 2016

Boot time is when you Turn on the target device up to the point where it downloads the bootstrap file. The bootstrap file contains the BOOTSTRAP PROGRAM


A target device initiates the boot process by first loading a bootstrap program. A bootstrap program is a small program that runs before the operating system is loaded. Provisioning Services uses a special bootstrap program that initializes the streaming session between the target device and the Provisioning Server. After this session starts, the operating system begins to be streamed and loaded from the vDisk that was initiated.

There are three ways that a target device may load the bootstrap program.

  • Over the network, via Preboot eXecution Environment (PXE)
  • From a boot device stored on attached media
  • From a BIOS Embedded bootstrap (OEM versions only)

Source: Citrix DOCS – BootStrap Program





TFTP Explanation:

TFTP Service is a basic TFTP you can see anywhere else – Just sits there with the boot strap file, waits for someone/somebody to request it . When somebody (usually a target device) requests it, it uses the TFTP protocol to deliver the bootstrap file

Now, in order to get the bootstrap file when you perform a PXE booting, you need two pieces of information

  1. The IP Address of the Server or [Server name]
  2. The name of the bootstrap file [filename of the bootstrap file

So in order to do a Network boot via PXE, those two pieces of information have to be provided for, to accomplish that

There a couple ways of doing that:

  1. Using Option 66/67 in your DHCP server. So when you use option 66/67:
    1. a target with PXE enabled, boots up
    2. It will send out a DHCP discover packet
    3. DHCP will respond to that discover packet with the offer that can contain all the normal DHCP information (IP, subnet mask, gateway, DNS, domain, but in addition to that information, it will also provide the IP address and the filename for the boot strap. It will then, with that information in hand go to the TFTP server and download the bootstrap file
  2. Using PXE

PXE explanation

Q. So, do you know what PXE service is used for?

A. It replaces Option 66 and 67

So, in a environment where you don’t want to use Option 66 and 67, you can enable the PXE Service in all your PVS servers. What happens here is the target boots up, and does a DHCP discovery (It will send out a DHCP discovery packet)

PXE services listens on port 67 which is the same port that DHCP listens on. So that discovery goes out and hits the DHCP server and will hit all PXE Services. DHCP will respond with the basic  DHCP information (IP, subnet mask, gateway, DNS, domain). It will NOT have in this case (since it was not configured) the option 66 and 67. However, all the PXE servers will respond with the IP of themselves and the boot strap file name. So when you use PXE services you use both PXE service and TFTP on the same server. The way this works i: if you have multiple PXE services, the first one that gets received by the target devices is the one being used; it  will contact the TFTP server and download the bootstrap


More to come:

TSB explanation:




Using ADSI Edit to validate an object SID such as an user or a computer

December 4, 2016


Let’s say you found an object SID but need to validate if that object SID is related to a AD component  Canonical Name (CN) . Example: Domain users have a object SID attribute like:


Using “ADSI Edit” on your Domain Controller, you can check if the object “Domain Users” have a object SID that matches the attribute above. Note that the “Object SID” and “Object GUID” are not the same thing and don’t have the same numbers, but they are listed next to each other in the attributes table of the object “Domain Users” in the ADSI Edit snap-in console

But in order to use ADSI Edit, you need to register the DLL first by typing on a command prompt:

regsvr32 adsiedit.dll 
Ideally you want to be on the same folder or the DLL is located. Normally if you download
the Support Tools, this is already done for you. But, if not, you need to make sure this
command works properly so you can register the DLL and start the ADSI EDIT snap-in)

On the Domain controller or on the server where you have access to AD Users and Computers, 
after registering the DLL you can start:

Using the ADSI Edit

ADSI Edit (Adsiedit.msc) is an MMC snap-in. You can add the snap-in to any .msc file through the Add/Remove Snap-in menu option in MMC, or just open the Adsiedit.msc file from Windows Explorer. The following figure illustrates the ADSI Edit interface. In the console tree on the left, you can see the major partitions Domain, Configuration, and Schema.

So by typing ADSIEDT.msc on a elevated command prompt you should be able to launch the snap-in

Right click and select Connect to… and take the default value to load the “Default Naming Context”

Something like this: LDAP://DC1.[domain name]/Default naming context where DC1 is the hostname of  the Domain controller

In the Advanced button you can specify the Port Number. When using ADSI Edit Type a port number if you do not want to use the default port for the LDAP or the LDAP Global Catalog protocol. The default LDAP port is 389. The default port for the Global Catalog is 3268.

Review this Microsoft Technet article on ADSI Edit for detailed information on the use of the tool

In my case I  expanded the Domain Name of my domain and expanded the CN=Users folder and located the “Domain Users” object and right click on it and selected the option “Properties”

One of the attributes listed was the object SID. I was able to validate that the object SID I found earlier matched the object SID of the object “Domain Users”


Unable to RDP to a 2012 R2 server

December 4, 2016

I have a Citrix Delivery Controller (DDC) and a Server VDA (SVDA)  in my lab, as part of my XenApp 7.11 environment. Both servers are 2012 R2 servers. I have Terminal Services role enabled by default on my SVDA because when you install Citrix software (Virtual deliver Agent or VDA) on a Server 2008 R2 or 2012 R2, the Terminal Services (TS) role is automatically installed, since it is a pre-requisite for the VDA. The DDC doesn’t have the Terminal Services Role installed by default (unless you install the VDA software on it, which is not considered Best Practices by Citrix), but Microsoft allows two RDP connections to a Server even if the Terminal Services role is not installed. Of course it is limited to local or domain administrators. One of the reasons this is possible is to allow either the local admin or the domain admin to install the full blown Terminal Services role if needed. Recently, I have been unable to RDP into the  DDC but had no problems RDP-“ing” to my SVDA.

After checking firewal settings and making sure they were disabled, I tried tel-netting via port 3389 from my SVDA to my DDC and was unable to do so. However, I was  able to telnet from another server to my SVDA via port 3389. So I suspected that my RDP listener on the DDC had an issue.

Sure enough, I compared the RDP listener registry key settings between the SVDA and the DDC. On my DDC there were a few binary values that did not match my SVDA. Obviously some of the values should be different since one server has the TS role installed (SVDA) and the other (DDC) doesn’t, but the vast majority of the binary values on the RDP listener registry  key should be quite similar on both 2012 R2 servers. The registry key for the RDP listener is located here:   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

These two keys particularly intrigued me:

fDisableExe -> set to 1 on the working SVDA but set to 0 (zero) on the non-working DDC

User Authentication – set to 1 on the working SVDA but set to 0 (Zero) on the non-working DDC


I changed both flags to 1 on the non-working DDC, to mimic the SVDA and VOILÁ, the RDP connection started to work again, MAGICALLY!

Note 1: After changing the two binary values on the registry, I rebooted the DDC for the changes to take effect.

Note 2: I did not test the behavior by only changing one binary value entry due to my own laziness, so it is quite possible that only one binary value change could have done the trick as well. If I were to guess I suspect the User authentication binary value could be the one, but that is only my guess!


Microsoft installs the RDP listener on all Windows machines by default when the Windows software is installed on a computer. This is for management purposes in case you want to manage the computer remotely.

So you should be able to see RDP listener registry key on all  Windows computers regardless of being a Server or Desktop OS. The RDP listener is not a very popular component and most end users don’t really know much about this component or that it even exists (unless you are an IT administrator). However, when corrupted, modified or customized , it will cause disruptions to a remote connection to the computer, like the disruption I had, so beware!

The only mysteries I did not solve was

  1. How the binary values changed on the DDC (since I’ve never touched that registry key myself before)?, or
  2. If it did not change (which is quite possible as well) what triggered the issue then? and
  3. What roles do those two binary values (User Authentication andfDisableExe)  have?
  4. Why did I decide to choose those two binary values since there were other values that also did not match. Was it my gut, my instinct? or pure luck? or would any value change do it?

These are all answers to be discussed and hypothesis that could be tested and discussed on another blog article . If you know the answer please share!

Additional Tip:

This is a good command to test if the RDP protocol is listening on port 3389, the default RDP port:

Telnet [hostname or ip address or FQDN] 3389 – If you get as an answer the cursor blinking on the top left of the CMD prompt screen, that is a good thing. That means the connection to that computer via RDP is enabled and the RDP protocol is listening on that port. If you get an message: “Connecting to [hostname]…could not open connection to the host, on port 3389: Connect failed” it really means that port 3389 is not opened on the destination host name

During my troubleshooting, telnetting within the server itself  it worked (telnet localhost 3389) but it failed from any other computer telnetting into the DDC

Some IT shops change the default port of RDP from 3389 to another number to prevent  end users from accessing the computer remotely or to prevent intrusions

I hope this helps!


*** === ***

side note:definition of voilá

used when something is being presented or shown to someone

SpeedScreenLatency Reduction Manager Client Side

November 18, 2016

Speed Screen Latency Reduction Manager (SLR) 101:

Make sure to read this full article from  BrianMadden article which has a great explanation of SLR. I pasted most of it further below under “Read More”

The important thing to remember is that Citrix Receiver (latest version 4.5 as of November 18th 2016) has a setting in its ADM tempate that enables SLR at the client level: It is kind of hidden under the “User Experience” – “Client Graphics settings”


Try enabling it a the end point device in case your end users are running Cirtix session on a slow connection remotely

Read the rest of this entry »

SSL and TLS under Citrix

November 13, 2016


In  Citrix  environments the theme security is always considered a top priority. As a matter in fact one of the mottos of the company is “We securely Deliver application and data”

Citrix flagship product: XenApp/XenDesktop focuses on delivering applications and desktops securely as this white paper suggests:

“XenApp keeps sensitive corporate information protected in the data center, but employees still need secure access to the XenApp infrastructure. Applications published using XenApp are accessible through Citrix Receiver™—a lightweight client that can be installed on any type of device,”

Citrix has two backend software packages to handle web authentication: Web Interface (5.4 was the latest and last version available) and StoreFront (3.7 is the latest version as of November 2016)

Web Interface 5.4 — – Is TLS 1.2, 1.1 supported?

No it’s not. Upgrade to StoreFront 3.x.
On page 173 of the product documentation guide for Web Interface 5.4 you will find the following paragraph:

” Transport Layer Security –
Transport Layer Security (TLS) is the latest, standardized version of the SSL protocol. The
Internet Engineering Taskforce (IETF) renamed it TLS when they took over responsibility for
the development of SSL as an open standard. Like SSL, TLS provides server authentication,
encryption of the data stream, and message integrity checks.
Support for TLS Version 1.0 is included in all supported versions of XenApp for Windows and
XenDesktop. Because there are only minor technical differences between SSL Version 3.0
and TLS Version 1.0, the server certificates you use for SSL in your installation also work
with TLS.
Some organizations, including U.S. government organizations, require the use of TLS to
secure data communications. These organizations may also require the use of validated
cryptography, such as Federal Information Processing Standard (FIPS) 140. FIPS is a standard
for cryptography.
Note: The maximum SSL/TLS certificate key size supported by the Web Interface for Java
Application Servers is 2048 bits.”

Here TLS 1.2 or 1.1 is nowhere mentioned, hence upgrade is highly recommended.
Also since WI 5.4 was designed in C# and support for C# has ended by Microsoft nearly two years ago any enhancement request will not be possible

The Wikipedia explanation:

“Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as “SSL”, are cryptographic protocols that provide communications security over a computer network.[1]Several versions of the protocols find widespread use in applications such as web browsing, email, Internet faxing, instant messaging, and voice-over-IP (VoIP). Websites use TLS to secure all communications between their servers and web browsers.”

Why using TLS and not SSL:

The TLS (Transport Layer Security) protocol has superseded SSL. Although many products support both SSL and TLS, and the term “SSL” is often used to describe both, the difference between SSL and TLS is crucial. Use TLS. SSL is no longer secure.

Cryptography in the TLS protocol:

Cryptography in the TLS protocol is selected by a TLS cipher suite, which is negotiated between the client and server. This defines the cryptographic algorithms that are used for the connection.

Cipher suites are named in the form TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. This can be interpreted as follows:

• TLS is the protocol (Transport Layer Security)

• ECDHE_RSA is the key exchange algorithm (Elliptic Curve Diffe-Hellman)

• AES_256_CBC is the cipher (Advanced Encryption Standard, Cipher Block Chaining)

• SHA384 is the (MAC) message authentication code (Secure Hash Algorithm)

Examining the key exchange algorithm, ECDHE indicates that this cipher suite offers forward security. RSA indicates that a RSA digital certifcate must be used.

Examining the cipher, AES_256_CBC indicates that this cipher suite uses a 256-bit key in CBC mode.

Examining the MAC, SHA384 indicates that this cipher suite uses the HMAC-SHA386 algorithm.

The cipher suite does not identify the version of the TLS protocol and many cipher suites are common to different TLS versions. Note: The naming scheme above is the one from the TLS standards. Some implementations, including OpenSSL and Citrix NetScaler, use a slightly different naming scheme for historical reasons. (For example, TLS1.2-ECDHE-RSA-AES-256-CBC-SHA384 corresponds to TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.)

Strong and weak cipher suites

In this context, a weak cipher suite is one that can be attacked successfully now or projected in the next few years. (An attack may be diffcult, but is at least possible.) Advances in technology, tools and techniques may weaken ciphers well before their initially projected lifespan and the known strength of ciphers should be periodically verifed through NIST and other trusted sources.

Cipher suites containing the following algorithms are generally considered weak:

• DES (although 3DES—also known as TripleDES or TDEA—is not generally considered weak)

• RC2

• RC4

Additionally, the so-called ‘export’ or ‘step-down’ cipher suites are weak. These cipher suites limit the length of the signing key to 512 bits, which can be broken by brute force. These weak ‘export’ cipher suites were devised to satisfy export considerations that have not applied for many years. Strong cipher suites can and should be used instead.

Hashing algorithms including the SHA1 and MD5 are also considered weak for signatures in digital certifcates, with SHA-256 being specifed as the minimum standard. The usage of previous algorithms is so weak that public certifcate authorities will no longer issue certifcates that use them. Digital certifcates using MD5 or SHA1 should be replaced. Some platforms, including Microsoft Windows, are already preventing their use.

In summary, for TLS today, the following are considered weak:


source: Citrix White Paper on SSL and TLS

Preferred cipher suites AES is a block cipher: every block cipher is used in a particular mode of operation. Three of these modes have been standardized within TLS, as part of the cipher defnition: • AES-CBC (Cipher Block Chaining) • AES-CCM (Counter with Cipher Block Chaining-Message Authentication Code). This mode is rarely used. • AES-GCM (Galois Counter Mode) The CBC mode is more widely supported than GCM, including in TLS version 1.0 and version 1.1. The GCM mode is often preferred to CBC mode, because: • It is higher-performance • It is resistant to side-channel attacks, specifcally padding oracle attacks such as Lucky Thirteen. (However, such attacks against CBC mode can be mitigated in other ways.) • It is resistant to adaptive plaintext attacks, specifcally the BEAST (Browser Exploit Against SSL/TLS) attack. (Again, this attack against CBC mode is mitigated in version TLS 1.1 or in other ways.) Some authorities prefer GCM: others nevertheless still prefer CBC

SSL/TLs in XenApp 7.x:

SSL 7.6:

“Configuring a XenApp or XenDesktop Site to use the Secure Sockets Layer (SSL) security protocol includes the following procedures:

  • Obtain, install, and register a server certificate on all Delivery Controllers, and configure a port with the SSL certificate. For details, see Install SSL server certificates on Controllers.

    Optionally, you can change the ports the Controller uses to listen for HTTP and HTTPS traffic.

  • Enable SSL connections between users and Virtual Delivery Agents (VDAs) by completing the following tasks:
    Requirements and considerations:

    • Enabling SSL connections between users and VDAs is valid only for XenApp 7.6 and XenDesktop 7.6 Sites, plus later supported releases.
    • Configure SSL in the Delivery Groups and on the VDAs after you install components, create a Site, create Machine Catalogs, and create Delivery Groups.
    • To configure SSL in the Delivery Groups, you must have permission to change Controller access rules; a Full Administrator has this permission.
    • To configure SSL on the VDAs, you must be a Windows administrator on the machine where the VDA is installed.
    • If you intend to configure SSL on VDAs that have been upgraded from earlier versions, uninstall any SSL relay software on those machines before upgrading them.
    • The PowerShell script configures SSL on static VDAs; it does not configure SSL on pooled VDAs that are provisioned by Machine Creation Services or Provisioning Services, where the machine image resets on each restart.

For tasks that include working in the Windows registry:

Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.”

Positional Parameters in Power Shell: understand them but don’t over use them

October 30, 2016



This PosH guru blog makes a good point; use Positional parameters in a interactive PoSh console but don’t use in scripts. Your goal is to write a better, clear and consistent code and positional parameters is more of a shortcut if you are in a worry but not considered best practices.

“Explanation: Positional and partial parameter names can be used for the interactive Powershell console to speed up our work, but not in scripts.

It takes more time to write the named parameter but your code will be more clear and consistent.

Positional parameters can be more difficult to read especially with cmdlets supporting multiple parameters.
Besides, the command will fail if the correct order is not respected (parameter order mixed up).

Moreover, with future versions of Powershell there is no guarantee that these parameters keep the same position.
A script created using positional parameters in the past could have a different behaviour in the future, but with named parameters there is no issue.

You can use Show-Command to see the Best Practice action as it will use the full cmdlet name and the named parameter.” source: PoSh guru

How to enable debug view for Android Logs

October 30, 2016

Android devices  have a unique way of providing USB debugging mode

See this link for complete article including nice screenshots:

How to Enable USB Debugging Mode on Android

This is a summary of the article above:

The ways to enable USB Debugging mode, which is accounted for the key step in Android rooting process, vary from one Android version to another. USB Debugging is required by adb, which is used for rooting, backing up, installing a custom ROM, tacking screenshots from computer and more.

For older version of Android (Android 2.0-2.3.x):Settings > Applications > Development > USB Debugging.

For newer versions of Android devices (Android 3.0- 4.1.x) Settings > Developer Options > USB Debugging

For the newest versions of Android devices (Android 4.2.x and higher.): In Android 4.2 and higher versions, the Developer Options menu and USB Debugging option have been hidden. In former 4.X versions of Android, USB Debugging option is under Developer Options menu

First, you need to enable “Developer Options Menu”.

  1. Click Menu button to enter into App drawer.
  2. Go to “Settings”.
  3. Scroll down to the bottom and tap “About phone” or “About tablet”,
  4. Scroll down to the bottom of the “About phone” and locate the “Build Number” field.

Now the fun part:

    1. Tap the Build number field seven times to enable Developer Options. Tap a few times and you’ll see a countdown that reads “You are now 3 steps away from being a developer.”
    2. When you are done, you’ll see the message “You are now a developer!”.
    3. Tap the Back button and you’ll see the Developer options menu under System on your Settings screen.

Now, you can enable USB Debugging mode.

4. Go to Settings>Developer Options>USB Debugging. Tap the USB Debugging checkbox

Android 5.0 Lollipop

To enable USB Debugging on Android 5.0 Lollipop is the same as Android 4.2.x.

  1. Settings > About Phone > Build number > Tap it 7 times to become developer;
  2. Settings > Developer Options > USB Debugging.

Warning USB Debugging should only be enabled when you need it. Leaving it enabled all the time is kind of a security risk for that this mode grants you high-level access to your device. Say if you connect your Android phone to a USB charging port in a public location, the port could use the USB access to your phone to access data on your phone or install malware. This could happen when and only when USB debugging mode is enabled.

To disable USB Debugging and other developer options when you don’t need them, slide the switch at the top of the screen to OFF.


source: Kingo Root –

The 98 verbs of Power Shell

October 30, 2016

Powershell contains 7 different groups of commands, as follows:

Common commands: 34 verbs

Data Commands: 24 verbs

Lifecycle Commands: 20 verbs

Diagnostics commands: 7 verbs

Communication commands: 6 verbs

Security commands: 6 verbs

Other commands: 1 verb (use)

This is the complete list as of October 29, 2016 when typing the command:



This list is based on the following version of PowerShell installed on my Windows 10 Desktop workstation:


Receiver Android Logs

September 20, 2016


When it comes to Citrix  Receiver Android logs, the collection of the logs per say, may not  provide any insights or  conclusive evidence of a connection issue between an Android device and a Store Front Server or Netscaler appliance. Sometimes you may need these logs too:

  • StoreFront debug view traces
  •  CDF (an event tracing controller/consumer utility from Citrix) from all the DDCs
  •  CDF from the application server (Citrix Scout can be used on the DDC and on the Server VDA or Desktop VDI in lieu of the CDF Trace (Scout has the CDF utility built-in)
  • Receiver Logs


Android Connection Issues to Store Front

This is a related article for Android devices not being able to add first store in Store Front

when connecting to Store Front using TLS 1.2 protocol. If you are using TLS 1.2 in your Store Front Server you can try (pasted here for convenience):


If your StoreFront Server is using TLS 1.2, you can force Receiver for Android to use the same TLS protocol as the StoreFront Server using the following workaround:

Create a text file named receiverconfig.txt with the following content:


Place the text file in the /sdcard/ directory on the device.

Stop Receiver for Android via the App Manager. (On Android 4.4.2, go to Settings > Application Manager > Receiver > Force Stop.)

Relaunch Receiver and add the account again.

More details about this procedure and the possible values for SslSdkProtocolNumber can be found in the Citrix Receiver for Android 3.8 OEM Reference Guide

Here’s an example that shows how to generate messages in thread output format using LogCat with thread format:  adb logcat v thread

Other Documents related to the topic

Citrix Docs

LogCat – Android Studio (Developer site)

adb logcat -v thread Controlling Log Output Format

What is a leap second?

September 13, 2016

Leap Seconds – Leap seconds have been added 26 times since 1972. They’re inserted at the end of the last day of either June or December. The leap second will be added to the world’s clocks at 23 hours, 59 minutes and 59 seconds Coordinated Universal Time (UTC) on December 31 2016. This corresponds to 6:59:59 p.m. Eastern Standard Time, when the extra second will be inserted at the U.S. Naval Observatory’s Master Clock Facility in Washington, DC

Does it affect CitrixxenApp/XenDesktop?

Answer here from last occurrence:

I don’t think it has changed

Does it affect Citrix Netscaler?

Answer here from the last Citrix update in June 2015:

Potential problems related to the leap second issue: