Industry news

Courage Empowers Citrix to Reach for the Stars

Citrix employee blogs - Mon, 10/02/2017 - 12:00

The Citrix value of Courage can be summed up as: “We dream big and are bold and selfless in pursuit of those dreams.” This blog, the fifth in a series about our core values, explains why Courage is so important

  Related Stories
Categories: Citrix, Virtualisation

New - NetScaler Gateway (Feature Phase) 12.0 Build 53.13

Netscaler Gateway downloads - Sat, 09/30/2017 - 18:30
New downloads are available for NetScaler Gateway
Categories: Citrix, Commercial, Downloads

New - NetScaler Gateway (Maintenance Phase) 11.1 Build 55.13

Netscaler Gateway downloads - Sat, 09/30/2017 - 18:30
New downloads are available for NetScaler Gateway
Categories: Citrix, Commercial, Downloads


Wag the real - Alain Assaf blog - Sat, 09/30/2017 - 11:35
A list of articles/blog posts to review, research, or archive EUC/Virtualization/Scripting Secure Deployment Guide for NetScaler App Layering and AntiVirus Best Practices Citrix App Layering 45. Available (requires MyCitrix login and active CSS) The Ultimate Golden Image Automation Guide – Part 3 Tech/Nerd/Gadget/Gaming Thanks for reading, Alain Advertisements Filed under: Always Be Learning, Automation Tagged: … Continue reading WAGTHEREAL DIGEST – SEPTEMBER 30 2017 →
Categories: , Citrix, Virtualisation

September News round-up

The Iconbar - Sat, 09/30/2017 - 06:05
Some things we noticed in the RISC OS world - what did you see?

R-Comp release an update for their !DualHead software.

Elesar offered a free AMCOG Games bundle with the Titanium.

Adrian Lees announced on Iconbar that Aemulor would no longer be sold as a commercial product but would continue in development.

No comments in forum

Categories: RISC OS

Docker’s routing mesh available with Windows Server version 1709

Microsoft Virtualisation Blog - Tue, 09/26/2017 - 05:04

The Windows Core Networking team, along with our friends at Docker, are thrilled to announce that support for Docker’s ingress routing mesh will be supported with Windows Server version 1709.

Ingress routing mesh is part of swarm mode–Docker’s built-in orchestration solution for containers. Swarm mode first became available on Windows early this year, along with support for the Windows overlay network driver. With swarm mode, users have the ability to create container services and deploy them to a cluster of container hosts. With this, of course, also comes the ability to define published ports for services, so that the apps that those services are running can be accessed by endpoints outside of the swarm cluster (for example, a user might want to access a containerized web service via web browser from their laptop or phone).

To place routing mesh in context, it’s useful to understand that Docker currently provides it, along with another option for publishing services with swarm mode–host mode service publishing:*

  • Host mode is an approach to service publishing that’s optimal for production environments, where system administrators value maximum performance and full control over their container network configuration. With host mode, each container of a service is published directly to the host where it is running.
  • Routing mesh is an approach to service publishing that’s optimized for the developer experience, or for production cases where a simple configuration experience is valued above performance, or control over how incoming requests are routed to the specific replicas/containers for a service. With ingress routing mesh, the containers for a published service, can all be accessed through a single “swarm port”–one port, published on every swarm host (even the hosts where no container for the service is currently running!).

While our support for routing mesh is new with Windows Server version 1709, host mode service publishing has been supported since swarm mode was originally made available on Windows. 

*For more information, on how host mode and routing mesh work, visit Docker’s documentation on routing mesh and publishing services with swarm mode.

So, what does it take to use routing mesh on Windows? Routing mesh is Docker’s default service publishing option. It has always been the default behavior on Linux, and now it’s also supported as the default on Windows! This means that all you need to do to use routing mesh, is create your services using the --publish flag to the docker service create option, as described in Docker’s documentation.

For example, assume you have a basic web service, defined by a container image called, web-frontend. If you wanted to publish this service to port 80 of each container and port 8080 of all of your swarm nodes, you’d create the service with a command like this:

C:\> docker service create --name web --replicas 3 --publish 8080:80 web-frontend

In this case, the web app, running on a pre-configured swarm cluster along with a db backend service, might look like the app depicted below. As shown, because of routing mesh clients outside of the swarm cluster (in this example, web browsers) are able to access the web service via its published port–8080. And in fact, each client can access the web service via its published port on any swarm host; no matter which host receives an original incoming request, that host will use routing mesh to route the request to a web container instance that can ultimately service that request.

Once again, we at Microsoft and our partners at Docker are proud to make ingress mode available to you on Windows. Try it out on Windows Server version 1709, and using Docker EE Preview*, and let us know what you think! We appreciate your engagement and support in making features like routing mesh possible, and we encourage you to continue reaching out with feedback. Please provide your questions/comments/feature requests by posting issues to the Docker for Windows GitHub repo or by emailing the Windows Core Networking team directly, at

*Note: Ingress mode on Windows currently has the following system requirements:


Categories: Microsoft, Virtualisation

Delivering Safer Apps with Windows Server 2016 and Docker Enterprise Edition

Microsoft Virtualisation Blog - Tue, 09/05/2017 - 09:00

Windows Server 2016 and Docker Enterprise Edition are revolutionizing the way Windows developers can create, deploy, and manage their applications on-premises and in the cloud. Microsoft and Docker are committed to providing secure containerization technologies and enabling developers to implement security best practices in their applications. This blog post highlights some of the security features in Docker Enterprise Edition and Windows Server 2016 designed to help you deliver safer applications.

For more information on Docker and Windows Server 2016 Container security, check out the full whitepaper on Docker’s site.


Today, many organizations are turning to Docker Enterprise Edition (EE) and Windows Server 2016 to deploy IT applications consistently and efficiently using containers. Container technologies can play a pivotal role in ensuring the applications being deployed in your enterprise are safe — free of malware, up-to-date with security patches, and known to come from a trustworthy source. Docker EE and Windows each play a hand in helping you develop and deploy safer applications according to the following three characteristics:

  1. Usable Security: Secure defaults with tooling that is native to both developers and operators.
  2. Trusted Delivery: Everything needed to run an application is delivered safely and guaranteed not to be tampered with.
  3. Infrastructure Independent: Application and security configurations are portable and can move between developer workstations, testing environments, and production deployments regardless of whether those environments are running in Azure or your own datacenter.

Usable Security Resource Isolation

Windows Server 2016 ships with support for Windows Server Containers, which are powered by Docker Enterprise Edition. Docker EE for Windows Server is the result of a joint engineering effort between Microsoft and Docker. When you run a Windows Server Container, key system resources are sandboxed for each container and isolated from the host operating system. This means the container does not see the resources available on the host machine, and any changes made within the container will not affect the host or other containers. Some of the resources that are isolated include:

  • File system
  • Registry
  • Certificate stores
  • Namespace (privileged API access, system services, task scheduler, etc.)
  • Local users and groups

Additionally, you can limit a Windows Server Container’s use of the CPU, memory, disk usage, and disk throughput to protect the performance of other applications and containers running on the same host.

Hyper-V Isolation

For even greater isolation, Windows Server Containers can be deployed using Hyper-V isolation. In this configuration, the container runs inside a specially optimized Hyper-V virtual machine with a completely isolated Windows kernel instance. Docker EE handles creating, managing, and deleting the VM for you. Better yet, the same Docker container images can be used for both process isolated and Hyper-V isolated containers, and both types of containers can run side by side on the same host.

Application Secrets

Starting with Docker EE 17.06, support for delivering secrets to Windows Server Containers at runtime is now available. Secrets are simply blobs of data that may contain sensitive information best left out of a container image. Common examples of secrets are SSL/TLS certificates, connection strings, and passwords.

Developers and security operators use and manage secrets in the exact same way — by registering them on manager nodes (in an encrypted store), granting applicable services access to obtain the secrets, and instructing Docker to provide the secret to the container at deployment time. Each environment can use unique secrets without having to change the container image. The container can just read the secrets at runtime from the file system and use them for their intended purposes.

Trusted Delivery Image Signing and Verification

Knowing that the software running in your environment is authentic and came from a trusted source is critical to protecting your information assets. With Docker Content Trust, which is built into Docker EE, container images are cryptographically signed to record the contents present in the image at the time of signing. Later, when a host pulls the image down, it will validate the signature of the downloaded image and compare it to the expected signature from the metadata. If the two do not match, Docker EE will not deploy the image since it is likely that someone tampered with the image.

Image Scanning and Antimalware

Beyond checking if an image has been modified, it’s important to ensure the image doesn’t contain malware of libraries with known vulnerabilities. When images are stored in Docker Trusted Registry, Docker Security Scanning can analyze images to identify libraries and components in use that have known vulnerabilities in the Common Vulnerabilities and Exposures (CVE) database.

Further, when the image is pulled on a Windows Server 2016 host with Windows Defender enabled, the image will automatically be scanned for malware to prevent malicious software from being distributed through container images.

Windows Updates

Working alongside Docker Security Scanning, Microsoft Windows Update can ensure that your Windows Server operating system is up to date. Microsoft publishes two pre-built Windows Server base images to Docker Hub: microsoft/nanoserver and microsoft/windowsservercore. These images are updated the same day as new Windows security updates are released. When you use the “latest” tag to pull these images, you can rest assured that you’re working with the most up to date version of Windows Server. This makes it easy to integrate updates into your continuous integration and deployment workflow.

Infrastructure Independent Active Directory Service Accounts

Windows workloads often rely on Active Directory for authentication of users to the application and authentication between the application itself and other resources like Microsoft SQL Server. Windows Server Containers can be configured to use a Group Managed Service Account when communicating over the network to provide a native authentication experience with your existing Active Directory infrastructure. You can select a different service account (even belonging to a different AD domain) for each environment where you deploy the container, without ever having to update the container image.

Docker Role Based Access Control

Docker Enterprise Edition allows administrators to apply fine-grained role based access control to a variety of Docker primitives, including volumes, nodes, networks, and containers. IT operators can grant users predefined permission roles to collections of Docker resources. Docker EE also provides the ability to create custom permission roles, providing IT operators tremendous flexibility in how they define access control policies in their environment.


With Docker Enterprise Edition and Windows Server 2016, you can develop, deploy, and manage your applications more safely using the variety of built-in security features designed with developers and operators in mind. To read more about the security features available when running Windows Server Containers with Docker Enterprise Edition, check out the full whitepaper and learn more about using Docker Enterprise Edition in Azure.

Categories: Microsoft, Virtualisation

Block Windows XP using selective Ciphers on Citrix NetScaler

Henny Louwers Blog - Tue, 05/06/2014 - 09:48
As you probably know Windows XP is no longer being supported by Microsoft. No (security) updates will be made available for Windows XP making it possibly vulnerable for future exploits. As an organization you will have to decide what you are going to do about these (probably unmanaged) Windows XP workplaces. There will still be […]
Categories: Virtualisation

XenApp 6.5…incoming!

Paul Lowther - Fri, 02/17/2012 - 23:05

Hey folks,

I know it’s been a while and I’m still getting visits to the site.  A lot of the information I posted here is still valid, so thanks for your continued visitations.

I’m just about to embark on getting XenApp 6.5 put into our environment, based on Windows 2008 R2 (of course).  Whereas I won’t be doing the direct engineering myself, I’ll be heading up the team doing it (stuff happens, people move on) but I’ll be able to bring you information as it comes in.

So, keep tuned in.

What’s more we’re looking to do a sizeable implementation of XenDesktop on XenServer too, so I’ll be sure to update you on some of that too.

If you have any requests, let me know – I’ll be sure to try to get the info!


Categories: Citrix

Citrix Receiver and Juniper SSLVPN

Paul Lowther - Sat, 10/02/2010 - 18:25

What do you do if you have a requirement to have your Citrix Farm(s) available outside of the company firewall. ‘Available’ meaning usable on any device, become truly device agnostic!

You could punch some holes through your firewall and hope it meets the stringent company security regulations.

You could buy a Citrix Netscaler solution and use their in-built Access Gateway functionality to ‘easily’ allow ICA traffic into your network.

But…What if your company had already invested in SSLVPN technology and couldn’t justify Netscaler?

The answer, if you chose Juniper, which many companies do due to it’s standing in the technology space and magic quadrant position with Gartner and Forrester, is actually all rather simple.

On September 8th, Juniper released their new Junos Pulse app for iOS4.1 and above. This means that any device currently compatible with iOS4.1 can utilize an SSL connection through the Juniper devices, into a secure company network. Once the connection is established, you can fire up Citrix Receiver, put in your simple connection string for your farm and hey presto, access to your published applications and desktops on XenApp and XenDesktop.

OK, so we’re not device agnostic yet, but…

iOS4.2 is out in November, which will be release for the iPad, a big game changer for mobile computing due to it’s portability and screen real estate (self confessed fanboy!), which will mean Junos Pulse will work immediately, once installed and connected to your SSLVPN device.

For the non-Apple devices, I have it on good authority that Droid, Symbian, Windows Mobile and Blackberry are all in Beta development at the moment and will be released ‘soon’. Great news…and a step towards device agnostic usage, so long as there is a Citrix Receiver for your platform too.

Getting it to work:

Installing the app is as simple as any app from the App Store, configuring it is also pretty simple, what’s more, with the Apple iPhone Configuration Tool for OSX/Windows v3.1, you can create pre-configured connections for your device, which does the ‘hard’ work for your end users!

Configuring the Juniper SSL device is fairly simple too, as long as you are using the NetworkConnect, function your device will have access, albeit fairly pervasive, to the network you’re connecting to.

What do I recommend you do is:

Set up a separate realm for mobile devices, which you specify as the connection string
Create a new sign-in page that is friendly to small screens – check out the Juniper knowledge base for a sample download.
Limit the devices you want to have connect by specifying the client device identifier.
Limit the sign-in screen to be available to the *Junos* browser only.
Add black lists of network locations you don’t want everyone to have access to. These could be highly confidential data repositories or your ‘crown jewels’.
Add white lists of citrix servers you want your folks to have access to while on the network, or if you’re happy that the blacklist is sufficient, allow * for a more seamless and agile implementation which will not need adjustment as your farm grows.

There is a lot of flexibility in the solution and depending on your security needs you can mix and match some of these ideas and more in what constitutes a valid policy for your company. The more controls you add, the more you may need to revisit the configuration as devices arrive and requirements change.

Once you are up and running with NetworkConnect you can configure your Citrix Receiver client, connect and start using your Citrix apps strait away.

I was impressed how quick it was to achieve and painless the process has been made.

I don’t work for Juniper and have only recently become familiar with the technology but in my mind, Junos Pulse is a complete breath of fresh air. In forthcoming releases there will be host checkers and cache cleaners etc to ensure the device is adequately secure before allowing connection.

The area of mobile security is still in it’s infancy, it will be interesting to see if Juniper keeps up with the requirements for more security, or my hope is be the lead for others to follow!


Categories: Citrix

Citrix Merchandising Server 1.2 on VMWare ESX (vSphere)

Paul Lowther - Sun, 03/21/2010 - 10:49

I recently acquired (yesterday) the Tech Preview version of Mechandising Server 1.2 from Citrix, which is specifically packaged for use on VMWare ESX.

Version 1.2 has been out or a short while, and whereas I had it running rather well on a XenServer, my company is a VMWare-only place right now, so getting this into a Production state would have meant jumping through several hoops.  I attempted to convert the Xen package over to VMWare but consistently got issues with the XML data in the OVF.

The new VMWare packaged file, which is around 450Mb, imported without a hitch!  Now I’m up and running on the platform of choice and this should make it easier for me to use in Production!  Good news!

Citrix recommends 2CPUs and 4Gb Ram for the instance.  Depending on your scale of usage, you can get it up and running with 1CPU and 1Gb RAM but that really does depend on how large your Directory data is.  For testing, I recommend 2Gb RAM, although it’s simple to adjust when you are more familiar with the load that is required for your environment.

If I find any gotchas with the configuration or getting Receiver/Plug-ins working with the Web Interface, I’ll let you know!

Thanks for reading, leave a comment!


Categories: Citrix

AppSense 8.0 SP3 CCA Unattended

Paul Lowther - Fri, 03/19/2010 - 14:03

If you’re wanting an unattended installation of you AppSense CCA (Client Communications Agent) you will want to look here.

This is documented in the Admin Guide but I missed it on my first run-through.

The installation is the same for the 32-bit or 64-bit version, simply call the right MSI for your server type.  This is also true for the compatible Operating System versions, there’s only one per architecture but covers all compatible OS, which keeps it relatively simple.

Installation Script @echo off REM *** SETTING UP THE ENVIRONMENT NET USE M: "\\server\share\folder" /pers:no SET INSTALLDIR=M:\ REM **** Installing the AppSense Communications Agent (WatchDog agent installed also!) REM **** Set this VARIABLE for your own (primary) Management Server SET APPSENSESITE=SERVERNAME ECHO Installing AppSense Communications Agent.. cd /d %INSTALLDIR%\AppSenseCCA SET OPTIONS=INSTALLDIR="D:\Program Files\AppSense\Management Center\Communications Agent\" SET OPTIONS=%OPTIONS% WEB_SITE="http://%APPSENSESITE%:80/" SET OPTIONS=%OPTIONS% WATCHDOGAGENTDIR="D:\Program Files\AppSense\Management Center\Watchdog Agent\" SET OPTIONS=%OPTIONS% GROUP_NAME="ZeroPayload" SET OPTIONS=%OPTIONS% REBOOT=REALLYSUPPRESS /qb- /l*v c:\setup\log\cca.log START /WAIT MSIEXEC /i ClientCommunicationsAgent32.msi %OPTIONS%

This will install the CCA, set the installation folders, choose your “preferred” Management Server and then add it to a Deployment Group.

Management Console Considerations

One requirement for the Deployment Group is that it set for “Allow CCAs to self-register with this group”

This is set in the Management Console, in the group you have created, called ZeroPayload here, under the Settings section.  Putting a tick in the box is sufficient to complete the registration setting.

Now, a server will be able to join the group with the above unattended script.

What I have done, to manage how and when the agents and pacakages are deployed, is set the “Installation Schedule” to be set to “At Computer Startup – Agents are installed only when computers are started“.  I have added all the agents into this group but no PACKAGE payloads.  If you now reboot the server at your convenience, once the CCA is installed (in my case part of a wider XenApp install) the server will install the agents and immediately REBOOT the server one more time, since you need to remember that the Performance Manager agent will automatically issue a reboot request upon installation.

If you were to set this as “Immediate” in the Installation Schedule, there would be no control over when your server reboots.  Many people fall foul of that nuance of PM as it’s easy to forget (I’m sure the guys at AppsSense forget that on occasion too!).

One very cool behaviour is that you can add both 32-bit and 64-bit agents into this Deployment Group and your server will only install the version it needs for the given architecture.

So now your server is configured and ready for it’s final deployment.  If you’re like me and have  number of active Deployment Groups, some with a slightly different package payload, you can use this method initially, then move your server to the required deployment group.  If all agent versions are the same, and in the beginning they certainly should be, all that will be deployed when you move to another group is the Packages, and these don’t force a reboot.

One last thing to consider.  Any Environment Manager packages that have “Computer” settings will not be invoked until the next reboot.

So… there you have it in a nutshell.

Leave me a comment if you have experiences to share.


Categories: Citrix

XenApp PowerShell Command Pack CTP3

Paul Lowther - Fri, 03/19/2010 - 09:09

I’ve recently started looking at PowerShell 2.o and bought the “for dummies” book to get me started.  My immediate need for usage of PowerShell was to automate some XenApp farm configurations.  This is where the XenApp Command Pack CTP3 comes into the picture.


A pre-requisite, in addition to installing the following two components, is to install .Net Framework 3.5SP1 – this is specific to the XenApp Command Pack and use of CTP3 functionality.

NOTE: Anywhere a  is shown, this is not intended as line break merely a line continuation to overcome the shortcomings in WordPress!

ECHO+ ECHO Installing Windows Management Framework Core (including PowerShell 2.0).. start /wait WindowsServer2003-KB968930-x86-ENG.exe ♦ /quiet /log:c:\setup\log\WMF-PS.log /norestart ECHO Installing XenApp PowerShell Commands.. cd /d "%INSTALLDIR%\Citrix Presentation Server" start /wait msiexec /i Citrix.XenApp.Commands.Install_x86.msi ♦ INSTALLDIR="D:\Program Files\Citrix\XenApp Commands" ♦ /norestart /qb /l*v c:\setup\log\xa-cmds.log

Now I have the Commands installed, it’s relatively simple for me to manipulate the farm in any way I want! As far as I can see, anything that is configurable within the AMC (XenApp 5.0 FP2) can be manipulated with a PowerShell command. This includes both farm settings and server settings. I’ve also been able to set Server Groups, Server Console published icons, Administrator Access, Lesser-mortal-being Access (defined access rights) and more besides.

I would have added some of my code here but there are some sensitive items in it and would have to rewrite a lot just to display it.  It’s quite simple to get some quick results, believe me!

It’s a given that Citrix will increase their use of PowerShell in versions to come, such as FP3 and XenApp 6 for W2K8-R2. This for me can only be seen as a positive move!

I can’t recommend this one highly enough.  Check it out.

Leave a comment and thanks for reading.


Categories: Citrix

AppSense 8.0 SP3 Unattended Installation

Paul Lowther - Fri, 03/19/2010 - 08:18

It’s been a long time in coming but I finally got round to getting some progress with AppSense 8.0 @ work.

I don’t do anything unless I can automate it, so here’s my take on the unattended method for AppSense v8.0, in this case the files I used were SP3.  There is some great information in the documentation for the pre-requisites needed to get the software installed.  This is the condensed and automated sequence.  I recommend you read the documentation too!  One thing that is missing is how to do an unattended installation, which is where I felt it necessary to share my knowledge with you!

A word of warning, this isn’t as end-to-end as I’d hoped.  The pre-requisites and MSI installations are all you need to get the product running on your server but you still have to configure the product with the relevant databases for Management Server, Statistics Server and Personalisation Server, if you are using them.  I did manage to do a lot more with AppSense 7, like defining the database schema to use and setting the admin account to use etc, but I’ve since lost my snippets for v7 (an over zealous colleague being “tidy” on our code file server) and couldn’t find any settings within the MSI that looked like they would be relevant, so it’s install-then-configure this time!

My script here starts off with a server that already has IIS installed, but didn’t have BITS installed, so SYSOCMGR was used to add BITS.  If you’re installing IIS from scratch, ensure you add this component!

The IIS-BITS.inf file is simply:

[Components] BITSServerExtensionsISAPI = ON NOTE:  Anywhere I added the  symbol, it’s not intended as a line break!  I’m just overcoming the shortcomings in WordPress for long lines of continuous text. @echo off REM *** SETTING UP THE ENVIRONMENT NET USE M: "\\server\share\folder" /pers:no IF NOT EXIST M:\ GOTO FAULT SET INSTALLDIR=M:\ REM ** Enable BITS for IIS ECHO Enabling BITS for IIS START /WAIT sysocmgr.exe /i:%systemroot%\inf\sysoc.inf /u: ♦ "%INSTALLDIR%\AppSense\32-bit\IIS-BITS.inf" /r /x REM *** Installing Dot Net 3.5 ECHO .Net Framework 3.5.. cd /d "%INSTALLDIR%\32bit.kit\DotNet35" START /WAIT dotNetFx35sp1.exe /Q /PASSIVE /NORESTART REM *** Installing Visual C++ Runtime 2005 SP1 (needed for hotfixes etc) ECHO Visual C++ Runtime 2005 SP1.. cd /d "%INSTALLDIR%\32bit.kit\vcredist.2005.sp1" START /WAIT vcredist_x86.exe /q:a /c:"VCREDI~3.EXE ♦ /q:a /c:""msiexec /i vcredist.msi /qn"" " REM *** Install MS XML6 Runtime ECHO MSXML6.. cd /d "%INSTALLDIR%\AppSense\32-bit" START /WAIT msiexec /i msxml6.msi REBOOT=ReallySuppress ♦ /qb- /l*v "c:\setup\log\msxml6.log" REM *** Installing AppSense Components cd /d "%INSTALLDIR%\AppSense\32-bit" ECHO Installing 32-bit AppSense Management Server component.. START /WAIT MSIEXEC /i ManagementServer32.msi ♦ INSTALLDIR="D:\Program Files\AppSense\Management Center" ♦ ALLUSERS=TRUE REBOOT=ReallySuppress ♦ /l*v "c:\setup\log\AS-ManagementServer.log" ECHO Installing 32-bit AppSense Management Console.. START /WAIT MSIEXEC /i ManagementConsole32.msi ♦ INSTALLDIR="D:\Program Files\AppSense\Management Center" ♦ ALLUSERS=TRUE REBOOT=ReallySuppress ♦ /l*v "c:\setup\log\AS-ManagementConsole.log" /QB- ECHO Installing 32-bit AppSense Application Manager Console.. START /WAIT MSIEXEC /i ApplicationManagerConsole32.msi ♦ INSTALLDIR="D:\Program Files\AppSense\Application Manager" ♦ ALLUSERS=TRUE REBOOT=ReallySuppress ♦ /l*v "c:\setup\log\AMConsole.log" /QB- ECHO Installing 32-bit AppSense Environment Manager Console.. START /WAIT MSIEXEC /i EnvironmentManagerConsole32.msi ♦ INSTALLDIR="D:\Program Files\AppSense\Environment Manager" ♦ ALLUSERS=TRUE REBOOT=ReallySuppress ♦ /l*v "c:\setup\log\EMConsole.log" /QB- ECHO Installing 32-bit AppSense Performance Manager Console.. START /WAIT MSIEXEC /i PerformanceManagerConsole32.msi ♦ INSTALLDIR="D:\Program Files\AppSense\Performance Manager" ♦ ALLUSERS=TRUE REBOOT=ReallySuppress  ♦/l*v "c:\setup\log\PMConsole.log" /QB-

For the .Net Framework file, don’t go looking for dotNetFx35sp1.exe, since this is merely the download of 3.5SP1 renamed so it doesn’t look like standard 3.5, and was done for my own future sanity if nothing more.

.Net Framework 3.0 is the minimum requirement but I’m aligning all my current work on 3.5SP1 since I may wish to use PowerShell 2.0 as and when possible.  I certainly did for XenApp with favourable results (will post about that later).

Post Installation work:

Once the software is installed, you need to connect to or create the databases you’ll need for your choice of functionality you’re going to make active.

Click Start -> All Programs -> AppSense -> Management Center -> AppSense Management Server Configuration

Go through the GUI, tell it where your blank (but already created) schema resides, present it with some credentials and you’re set!

The only other step you *may* be faced with is that the configuration tool analyses the installation to see if there any anomalies.  These are termed as variances in the GUI.  For me, since I’m logged in as an Administrator anyway, I ask the GUI to repair all variances, in all locations.  Once done, the installation is complete.  The steps are very similar for the Statistics Server and Personalisation Server.  It is recommended (for larger installations) that you put Personalisation on it’s own server instance, but Management Server and Statistics Server can occupy the same instance.

I’m planning on installing the CCA with the XenApp base build, so I will likely post that unattended install next.

Leave a comment, thanks for reading.


Categories: Citrix

Citrix Merchandising Server 1.2

Paul Lowther - Fri, 03/19/2010 - 06:53

I’ve been experimenting with Merchandising Server recently.  Primary objective: To see what all the fuss is about.  How will this make my life (or at least the support team @ work)’s life easier?

Well on first look, it’s all looking rather good!  Here’s why:

  • Delivery of the Receiver software to any compatible device (Windows & Mac)
  • Delivery of Plugins (ICA aka Online/Offline Plugin, EdgeSight, Dazzle, EasyCall, etc)
  • Seamless Updating of new plugin versions (all fully customisable with rules for when to do or when to not do an action)

I can see our rather large user base (35k ICA installs and counting) being quite taken by the fact that they don’t have to seek out a “scripted” install to replace what they already have, we can do the “hard work” for them – and roll it back if a new version sucks (you know it happens occasionally!)

So what’s the catch:

Well since I am bound by the rules that *essentially* we are a VMWare shop at my place of employment, the Merchandising Server is a VM Appliance that is only available for those running XenServer.  This is a big disappointment.  Do you guys realise how many hoops I’d have to jump through to get a XenServer (or two) installed in Production.  Not only that but I’d have to write the documentation to support it, in addition to documenting the Merchandising Server, not a prospect I relish.

Look Citrix we know XenServer is a good product – and it’s free for simple implementations – but it’s not really “enterprise” thinking when you limit the use of a product like this.

But “WAIT”, I hear you say…breaking news…

The good folks at Citrix, in their infinite (albeit slightly tardy) wisdom have done the “enterprise” thing!  Whilst browsing around today, I noticed that they have just released a VMWare instance!  Now that is good news.

I do have a slight challenge though, my subscription level seems to be limiting my ability to acquire said item.  Fear not, I tell myself, I have an email sat in my Citrix Account Manager’s inbox, asking for assistance of the intervention kind!  If/when I get it, I’ll post about it.  If the step-by-step documentation sucks, I may even write that up too.

If you have client sprawl in your Citrix jurisdiction, I really do recommend you check out the Merchandising Server, it could pave the way for an integrated solution for the future!


Categories: Citrix

Google…Sesame Street

Paul Lowther - Tue, 11/10/2009 - 13:41

Today’s entry is brought to you by the letters J, P and G.

Sesame Street is 40 today and Google is paying homage by changing it’s image to commemorate this momentus day!

I know I spent many an hour clocked in front of the TV watching big bird and the gang…

Google's Image of the day...10th November 2009

Categories: Citrix


Subscribe to aggregator