Unattended StoreFront 3.x deployment with Ivanti Automation

Introduction:
A while back I needed to automate the deployment of Citrix StoreFront 3.x for a customer I was working for at the time. However it wasn’t perfect. It only did the installation of the software and didn’t do anything with stores, server groups and certificates. Since time was scarce these items were put on hold. However, I put them on my own ToDo-list with the goal to automate an (almost) complete deployment of StoreFront with Ivanti Automation and share it with anyone who would like to use it.

I will give a small walkthrough of the automation steps and why I made certain decisions and of course instructions on how to import and use them.
You can find the download link for the Ivanti Automation building blocks here and also at the bottom of this blog post.

These modules have been tested on Windows Server 2012 R2 and 2016 (with User Experience enabled) and up to StoreFront version 3.15.

Instructions:

Import the Ivanti Automation building block and change the following (global) variables in your Automation deployment:

Installation Account
Credentials for the account that will be used for software installation
Installation Account username
Username for the account that will be used for software installation
Software Source
Your software share, for which the installation account should have the appropriate rights

(And yes, there are two variables for the Installation Account. One for the complete credentials and one for just the username.)

After that, schedule the first module for the agent on the first StoreFront server to be and it will ask you for all the required information (Base URL, XenDesktop site name, XenDesktop Delivery Controllers and the StoreFront store name).
Schedule the second module for the agent on the second StoreFront server and it will ask you for the hostname or IP address of the first StoreFront server.
Of course, your software share should contain the Citrix StoreFront 3.x software which you can download from Citrix.com. Just extract the ISO to a folder on your software source and you should be fine. The module will ask for an exact location when scheduling.

The configuration of the stores and server group is done through PowerShell. I will add the configuration scripts below for the people who don’t want to use Ivanti Automation for deployment (if they exist ;-)).

I could have used more pre-defined Ivanti Automation tasks, but my goal was to make the scripts usable without Ivanti Automation for as much as possible.

Modules overview:

There are two modules in the building block:
StoreFront 3.x – Part 1 – First server – Install software & Configuration
StoreFront 3.x – Part 2 – Additional server – Install software & Join server group

Use the ‘Part 1’-module for deployment of the first server and the ‘Part 2‘ module for any additional servers (don’t run the additional servers all at once).

Modules walkthrough:

StoreFront 3.x – Part 1 – First server – Install software & Configuration

Add RES installation account to local administrators
For when you haven’t done this through GPO for example.
Add required Windows Features – Windows Server 2012 R2
With conditions for the Operating System
Add required Windows Features – Windows Server 2016
With conditions for the Operating System
Install StoreFront
Copy StoreFront shortcut to desktop
Personal thing. I prefer to have the specific management consoles for which the server is used to be visible for every administrator that logs on.
Reboot Computer
Add machine to StoreFront team
Not really necessary but handy for when you also use RES ONE Automation as a management tool.
Create StoreFront store
PowerShell script that creates the store, creates and binds a self-signed certificate and creates a redirect from the wwwroot to the created store.
Disable check publisher’s certificate revocation
Console responsiveness improvement.

StoreFront 3.x – Part 2 – Additional server – Install software & Join server group

Add RES installation account to local administrators
Add required Windows Features – Windows Server 2012 R2
Add required Windows Features – Windows Server 2016
Install StoreFront
Copy StoreFront shortcut to desktop
Reboot Computer
Add machine to StoreFront team
Join existing StoreFront server group
Add machine to StoreFront team

Known issues:

– When configuring StoreFront for the first time it needs to create an initial store. However with this store the available options are limited. So in my PowerShell script, an initial store will be created, the definitive store will be created and after that the initial store will be deleted (not really an issue, but still worth mentioning).

Footnote:

That’s it again for now. Try the modules if you like and let me know if you have any problems. I will also look into the automated deployment of Director, Licensing and Provisioning Services. So stay tuned. 😉

DISCLAIMER: This is just my take on the automation of StoreFront 3.x with Ivanti Automation. So if you have any suggestions on how to improve these modules: I would be very happy to hear it. As for the scripts below: I’m in no way an expert PowerShell scripter, so it might not always be the most efficient code, but it gets the job done. Also, feel free to use it/alter it/publish it as your own.

Edit March 1st 2018:
This module has been tested with StoreFront 3.14 and Ivanti Automation 10.2.100.0 and works accordingly.

Edit July 23rd 2018:
Revised the scripts and tested with StoreFront 3.15 and Ivanti Automation 2018.1.

Edit August 2nd 2018:
It seems that during the joining process the StoreFront servers use a randomly selected port. This is not a problem for the Windows Firewall (if active) since the exceptions are created for the application and not a specific port. However, if both StoreFront servers are in seperate networks with a firewall between them you can set a specific port. Check Citrix article CTX101810 for more information. But I have NOT tested this myself.
Big thanks to Mark for pointing this out.

PowerShell scripts:
Create StoreFront store

Join existing StoreFront server group

Building blocks:

387 total views, 1 views today

13 thoughts on “Unattended StoreFront 3.x deployment with Ivanti Automation

  1. Mark

    I came across your interesting blog post while searching for a script to use in my lab. I am trying to configure a Primary and Secondary Storefront server but my powershell skills are very basic. Would you be able to provide me a few tips on how I could use your script to automate the installation without RES.

    Thanks!

    Reply
    1. Chris Jeucken Post author

      Mark,

      Well basically for the configuration you could use the scripts that are in the blog. Just replace the ‘user defined variables’ with your settings. (When using RES ONE Automation they will be filled out by the module/project parameters)
      For the installation itself you could check the following page:
      https://docs.citrix.com/en-us/storefront/3-9/install-standard.html
      (Section ‘To install StoreFront at a Command Prompt‘)

      Let me know if that helps you.

      Greetings,
      Chris

      Reply
  2. Mark

    Hello Chris,
    Thank you so you much for your reply. I see what you mean, and I managed to install and configure the Primary SF servers but when I use the Join script by changing the value of $SFExistingServer = “sft01.lab.local” which is my primary SF. But each time I run it on my secondary storefront machine, I am getting the below error. I am running the script using the local administrator context. I can map a drive to \\sf01.lab.local\c$ but for some reason the script is not able to connect. Both Storefront server are on the same subnet so no firewall rules issue.
    Not sure what I am doing wrong.
    Thanks again,
    Mark

    New-PSSession : [sft01.lab.local] Connecting to remote server sf01 failed with the following error message : WinRM cannot process
    the request. The following error with errorcode 0x8009030e occurred while using Kerberos authentication: A specified
    logon session does not exist. It may already have been terminated.
    Possible causes are:
    -The user name or password specified are invalid.
    -Kerberos is used when no authentication method and no user name are specified.
    -Kerberos accepts domain user names, but not local user names.
    -The Service Principal Name (SPN) for the remote computer name and port does not exist.
    -The client and remote computers are in different domains and there is no trust between the two domains.
    After checking for the above issues, try the following:
    -Check the Event Viewer for events related to authentication.
    -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or
    use HTTPS transport.
    Note that computers in the TrustedHosts list might not be authenticated.
    -For more information about WinRM configuration, run the following command: winrm help config. For more
    information, see the about_Remote_Troubleshooting Help topic.
    Other Possible Cause:
    -The domain or computer name was not included with the specified credential, for example: DOMAIN\UserName or
    COMPUTER\UserName.
    At Z:\Applications\Citrix\Configure – Storefront\Configure_SEC_StoreFront_v2.ps1:38 char:15
    + $PSSession = New-PSSession -ComputerName $SFExistingServer
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
    gTransportException
    + FullyQualifiedErrorId : 1312,PSSessionOpenFailed

    Reply
  3. Mark

    HI Chris,
    Please ignore my previous reply. I did some research into the error message: The following error with errorcode 0x8009030e occurred while using Kerberos authentication: A specified logon session does not exist. It may already have been terminated.

    The reason I am encountering the issue is due to running the script as a local administrator. I tried to add the trust of the primary storefront server – winrm set winrm/config/client ‘@{TrustedHosts=”sft01.lab.local”}’ but the join still errors out.

    Because I am using MDT to deploy the Server OS and Storefront, it uses the local admin context and the other thing I didn’t mention previously is I am using WS2016 instead of WS2012R2.

    Would you be able to shed any light on how I could port your scripts into my MDT lab.

    Thanks,
    Mark

    Reply
    1. Chris Jeucken Post author

      Mark,

      As long as you are running the script under local administrator you would need to provide credentials to the New-PSSession line (line 38) to connect to the primary StoreFront server (The local administrator of the new server you are deploying doesn’t have any rights on the primary StoreFront server).

      That would result into replacing that line with something like this:

      (Although nicer would be to put the $Username & $Password line in the User defined variables section)

      However, this would mean you have a password in clear text in your MDT scripts. So I would recommend running the script under a domain account from MDT instead of a local admin account running a script that contains a password.

      Let me know if this helps.

      Greetings,
      Chris

      Reply
  4. Mark

    Hello Chris,
    Hope this note finds you well and off to a good start to your summer break 🙂
    Apologies for the delay in getting back – I got busy at work and my automation project ground to a halt.

    I investigate the issue I was experiencing and found that the Network Discovery and File Sharing was disabled on the newly built existing SF servers. So i fixed the FW and added the Credentials to the script and run the Join script.

    The scrpt now runs and it connects to the Existing SF server and creates the C:\_CONFIG and the SFPasscodeScript.ps1 script. Then I get a message:
    ERROR: Unable to establish existence of the account specified.
    SUCCESS: Attempted to run the scheduled task “SFPasscodeScript”

    The error is reported on Line 58
    $SFPasscode = Get-Content -Path “$RemoteConfigPath\$RemoteConfigFolder\Passcode.txt”

    I checked to see if it creates the Passcode.txt file, and for some reason it not able to run the local script remotely.

    I ran the SFPasscodeScript script manually on the Existing SF machine it did create the Passcode.txt and I tested again by running the Join script it did delete the Passcode.txt file so gather it has RW permissions.

    I am almost there but… is there anything I should check?

    Thanks,
    Mark

    Reply
    1. Chris Jeucken Post author

      Mark,

      These error messages are seperate from each other:
      Error 1
      ERROR: Unable to establish existence of the account specified.
      SUCCESS: Attempted to run the scheduled task “SFPasscodeScript”

      That seems to be related to the scheduled task on the primary StoreFront machine.
      The script will create a scheduled task with a script to get the Passcode.
      It will then run this scheduled task, get the passcode from the file and remove the scheduled task, script and passcode file again.

      You could try to comment the removal lines (59, 60 and 61 in the original script) so everything will remain. You could then check the task scheduler to see if the task is there and if it did run accordingly.

      Error 2
      The error is reported on Line 58
      $SFPasscode = Get-Content -Path “$RemoteConfigPath\$RemoteConfigFolder\Passcode.txt”

      Since your last message I tested my own scripts to see if they still work with the most recent version of StoreFront (3.15) and ran into the same error.
      When the scheduled task runs it seems it’s not always fast enough retrieving the passcode and saving it to file before the script continues and grabs the passcode from the file to a variable. So you could increase the timeout in line 57 from 30 seconds to 60 seconds. That fixed my problem.
      (Maybe if I find the time I could change this to a loop that just waits for the task to end instead of waiting for a fixed amount of time)

      I hope this helps.

      Greetings,
      Chris

      Reply
  5. Mark

    Hello Chris,
    Thank you for your reply. One thing I realized is I didn’t mention that I am running the script in WS2016 and I am using Storefront 3.12.2000.8 (7.15 LTSR CU2) build.
    I tested it but for some strange reason it seems to fall short of being able to launch the SFPasscodeScript.ps1 script that it manages to create. I still get the same below messages.

    ERROR: Unable to establish existence of the account specified.
    SUCCESS: Attempted to run the scheduled task “SFPasscodeScript” ( It just sits there forever)

    I checked the Task Scheduler and it registers a failure to run a task called “KeyPreGen”

    Any ideas,I should try to make it work.
    Thanks,
    Mark

    Reply
    1. Chris Jeucken Post author

      Mark,

      Have you tried running the scheduled task manually from the task scheduler (context menu for task -> Run)?
      Do you get the same result?

      Which account do you see configured for the task? (Should be SYSTEM)

      Greetings,
      Chris

      Reply
  6. Mark

    Hello Chris,
    Thank you for getting back. I have made progress. The problem was being caused by the blocking of several ports between the Existing SF and the Secondary VLANs. In my lab I have configured multiple network subnets to similate physical locations. I changed the timeout settings in Line 68 to 400 secs and in Line 73 to 60 sec.

    Could you please tell me if the above changes I made are correct because I got a little confused about your previous mention to increase the delay from 30 sec to 60 sec in Line 57 or 73?

    Many thanks!
    Mark

    Reply
    1. Chris Jeucken Post author

      Mark,

      I meant 57. The delays you are mentioning are from the joining process.
      But the errors you received pointed to line 58 (‘$SFPasscode = Get-Content -Path “$RemoteConfigPath\$RemoteConfigFolder\Passcode.txt”‘).
      Which would mean the passcode file can’t be retrieved. Usually because it isn’t there yet or it’s a rights issue.
      So you need to give it more time to retrieve the passcode and save it to file.

      However, if you check the post you can see I have posted a new version of the script. This one will actually wait for the scheduled task to finish before moving on.

      I hope this helps.

      Greetings,
      Chris

      Reply
  7. Mark

    Hello Chris,
    Thank you for your reply. I must admit it was an oversight on my part to not have read your post again and download the new version of the script. It works perfectly without making and changes to the delay timers you have set. I have been testing it with the Storefront 3.12 (7.15 LTSR CU2).

    There is one thing I discovered which I thought I share and that is the Join process uses random p2p network ports for the Store, Subscription and Credential Wallet. In my lab I had Storefront in its own network segment and I ran into problems with the FW ports not being open more information can be found here https://support.citrix.com/article/CTX101810#StoreFront

    There is a mention in the KB on how to fix the port numbers but it doesn’t work if we are trying to deploy silently in an environment in which the Storefront servers are in its own network for example in multi-zone environments which is what I am trying to simulate in my lab environment.

    Chris! once again thank you so much for your help in getting the bottom of this.

    Regards,
    Mark

    Reply
    1. Chris Jeucken Post author

      Mark,

      That’s good to hear. 🙂
      I have added a note to the post with the ‘random ports’ issue and linked to the CTX101810 article.

      You could always create a PowerShell script that alters the config files accordingly (shouldn’t be too hard, but it might gives some issues when using the same script for newer StoreFront version).
      Let me know if you need any help with this.

      Greetings,
      Chris

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.