Creating a unique STA ID for XenApp 6 with provisioning 

# Change XenApp 6 STA ID to MAC Address
# Created by Michel Stevelmans - http://www.michelstevelmans.com

# Set location of CtxSta.config file
$Location = "${env:ProgramFiles(x86)}\Citrix\system32\CtxSta.config"

# Get the MAC address of the first NIC
$Nics = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IpEnabled = TRUE"
foreach ($Nic in $Nics)
    {
    $Mac = $Nic.MacAddress
    Break
    }

# Remove colons from MAC Address
$Sta = $Mac.Replace(":", "")

# Replace STA ID with MAC Address
(Get-Content $Location) | Foreach-Object {$_ -replace '^UID=.+$', "UID=STA$Sta"} | Set-Content $Location

# Restart Citrix XML Service
Restart-Service CtxHTTP

 

Source:

http://www.michelstevelmans.com/creating-unique-sta-id-xenapp-6-provisioning/

 

 

Office 2013 & Receiver for iPad

Microsoft just announced Office 2013 today, the very first thing I tried was the combination of Office 2013 and Citrix Receiver.  The new “Touch Mode” in Office 2013 made this XenDesktop+Outlook solution on iPad more practical than ever.  Thank you Microsoft, no more “track pad” mode on Citrix Receiver.


XenServer’s VM cannot shutdown and stuck/halt

I believe most of people had experience with VMs are stuck when one tries to shut it down or restart.  Sometimes this will happen if multiple commands are issued to Xenserver consecutively, but the Dom0 has problem to keep up with these tasks. Like the screenshot you see below, VMs are in their “yellow” status, which means they are trying to either shutdown, or restart.

In order to resolve such issue, we can use the command “xe task-list” to examined what tasks are in “pending” status.  Once we kill of one of these tasks, our VM will get back to work normally.

 

“xe task-cancel uuid=” to cancel the pending tasks

VASCO + NetScaler + SSO

A recent project raised an interesting point on the integration of token base authentication service with NetScaler AGEE and AG.  Due to the nature design of two factors authentication, users are required to enter AD’s username and password, Token’s PIN+PASSCODE. This may create hassles for users who are not tech-savey.  So what if we want to simplify user’s logon experience and at same time maintain a highest security standard as possible?

We all know there won’t be a problem when we implement two factors authentication on AGEE, since both Radius and LDAP authentication policies were processed separately, one authenticate against Radius Server (IDENTIKEY in VASCO’s case) and the other authenticate against Microsoft’s Active Directory. Even if we use the ICA-proxy mode on AGEE to achieve SSO with Web Interface is totally do-able.  But if we want to simplify the log-on process by requiring users to enter only username and VASO ‘s PING+PASSCODE (which means only one Radius authentication policy is present on AGEE), this will cause SSO to fail because the credential forward to backend Web Interface for second authentication will be rejected.  Why?  Due to the “One-Time-Password” generated by our token can only be authenticated once.

Thanks to VASCO’s clever workaround which had made SSO with only TOKEN authenciation possible!

If anyone is interested please read through the following deployment guide published by VASCO

XenDesktop in High Security Environments