Securing DDC XML Broker communication over HTTPS

For Citrix StoreFront and Delivery Controller communication, you need to specify XML service broker communication to travel over HTTPS or HTTP and specify a port such as 80 or 443. The XML service is used for application and desktop resource enumeration including handling user name and password data from StoreFront to DDCs.

This is configured within the StoreFront management console under Stores -> Manage Delivery Controllers, against one or more of your stores. The Citrix Broker Service participates in authenticating users, brokering a user connection to a least busy server and collecting application information to be presented to the user connecting in to StoreFront either via Receiver self-service or Receiver for Web.

By default, there is little to no configuration needed when you have configured StoreFront and your Delivery Controllers to communicate over HTTP port 80, as shown below.

1-min

If you want to secure communication by using HTTPS and port 443, or another port, notice what happens when I specify HTTPS/443 and then try and connect to Receiver for Web to retrieve my list of published applications.

2-min

As below, I get the message There are no apps or desktops available to you at this time.

3-min

Having a look in Event Viewer -> Applications and Services Logs -> Citrix Delivery Services on the StoreFront server, the following errors are recorded by the Citrix Store Service.

4-min

I already know the Citrix XML Service is running on my Delivery Controller because I checked. IIS is also not installed on my Delivery Controller virtual machine so no port clashing. What needs to be done is a port and application needs bound to a certificate for HTTPS communication to work. If IIS was installed on the Delivery Controller I simply bind certificates to the HTTPS IIS binding but most of the time in the enterprise the Delivery Controller does not run IIS.

In my case, my Delivery Controller’s FQDN is ddc.citrixpro.co.uk, and I want to secure communication over port 443. This means, for me, I need to install a computer certificate on my Delivery Controller with Server Authentication capabilities, issued to ddc.citrixpro.co.uk and then tied to port 443 and the Citrix Broker Service.

Firstly ensure you have the correct certificate issued to your Delivery Controller(s). If you are using a load balanced address for example make sure the certificate matches the FQDN of the load balanced address and is installed on all Delivery Controller servers. It is probably also helpful to add each Controller FQDN as a Subject Alternate Name, which can be used for the likes of STA communication from Citrix ADC.

Also make sure this load balanced address is configured within StoreFront under Edit Delivery Controllers. You can request a certificate via certreq, ADCS Web Enrolment, Group Policy or via the Certificate MMC snap-in for example. I have used Group Policy and automatically set the Computer certificate to auto-enrol to all domain computers in my domain. This results in the Delivery Controller machine getting a computer certificate as shown below.

5-min 6-min

At this stage. I can move on to using NETSH to bind ports and applications to my certificate. Firstly we need to collect two pieces of information. The certificate thumbprint and the Citrix Broker Service Application ID.

To obtain the certificate thumbprint, open the computer certificate and navigate to the Details tab -> Thumbprint. Make sure you copy the whole thumbprint string then delete any spaces so that all number and letters are together, using a text editor such as notepad.7-min

To obtain the Application ID of the Citrix Broker Service, open CMD, type wmic product where “name like ‘Citrix Broker Service'” get caption, identifyingnumber. Look for the Citrix Broker Service and take a copy of the App ID located with the {} brackets.8-min

Now with all the required information collected we can run the NETSH command (as an administrator) as shown below. This binds the certificate to our desired port and the Citrix Broker Service. Ensure the IPPORT field contains the IP of your own Delivery Controller server (not a load balanced IP) followed by the port you want to use for HTTPS communication which will likely be 443. If you have an IPv4 and IPv6 address configured on your Delivery Controller(s), use 0.0.0.0 for the IP address.9-min

You can then view the certificate binding by running netsh http show sslcert.10-min

If you want to remove an SSL binding you would run command http delete sslcert 192.168.0.102:443

Back over on Receiver for Web after a new log on the applications are showing.

11-min

It is also good practice to disable non SSL XML brokering on each DDC. To do this, start RegEdit.

Navigate to HKLM -> Software -> Citrix -> DesktopServer.

Create a DWORD with name XMLServicesEnableNonSSL and value 0x0

12-min

Additional notes:

  • Certificates will expire and renew meaning the thumbprint will change and as a result NETSH will have to be used again to bind the new thumbprint with the Citrix Broker Service.

79 Comments

  • Phil

    February 9, 2017

    If you’ve set up the DDC with IIS is it easy to change?

    Is it simply a case of unbinding the cert, remove IIS then use this method?

    Great website BTW..

    Reply
  • George Spiers

    February 9, 2017

    Yes absolutely, your Delivery Controller’s do not depend on IIS. If you are load balancing DDCs, take one offline and change one at a time etc.

    Reply
  • Jason

    August 14, 2017

    If we have 2 DDCs that are not behind a load balanced VIP, do we need an SSL cert for each DDC and bind the Certificate for each to the broker service? If so would that work, or would it be preferred to set them up behind a VIP and request a Cert for the VIP? I was under the impression that when you list the Delivery controllers in StoreFront it was load balancing them.

    Reply
    • George Spiers

      August 14, 2017

      You are correct in that when you specify multiple Controllers in the Edit Delivery Controller list, they are Load Balanced. However if you have a NetScaler, you are best to set up a VIP because it provides both Load Balancing and monitoring using health probes for failure detection. With a VIP, you enrol a certificate against the VIP FQDN and bind that certificate to your two DDCs. If you don’t use a VIP then yes enrol a certificate for each DDC FQDN and bind the correct certificate to each broker service.

      Reply
      • Tom

        September 26, 2017

        What is the max Key Size for the Certificate? Does a 4096 Cert work or is it limited to 2048 like Netscaler VPX? we receive an Error with 4096 (The TLS protocol defined fatal alert code is 43.)

        Reply
        • George Spiers

          September 26, 2017

          What version of StoreFront? I have StoreFront 3.12/DDC 7.15 working with 4K certificates.

          Reply
      • Steve

        November 30, 2017

        A wildcard cert would be sufficient as well?

        Reply
        • George Spiers

          November 30, 2017

          Yes that should work.

          Reply
  • SaaJ

    October 13, 2017

    Are any further changes required on Netscaler gateway to get this working externally?

    Reply
    • George Spiers

      October 13, 2017

      No as NetScaler talks to StoreFront, and StoreFront does the talking to your DDCs.

      Reply
      • Rilesh

        August 14, 2018

        Hi George, don’t you need to do any sta changes on netscaler to bind anything, otherwise It will show the STA’s marked down?

        Reply
        • George Spiers

          August 15, 2018

          STA is added to NetScaler not as a load balanced address, but as individual addresses. You can deploy a separate STA server, you could run STA over HTTP.

          Reply
          • Rikesh

            January 19, 2019

            Whats your thoughts for Delivery Controller and Storefronts on the same server

          • George Spiers

            January 28, 2019

            Small deployments less than 500 concurrent users, I would say OK. Larger deployments I might look at separating the roles out just so I can have granularity between upgrades and maintenance.

  • Anonymous

    January 7, 2018

    How can I set it when there are multiple DDCs?
    The thing you want to do is to use two sites for one storefront

    Reply
    • George Spiers

      January 8, 2018

      If you have two sites, you add both Delivery Controllers to the single StoreFront configuration. Just like I did above, only twice/for each site.

      Reply
  • ounet

    February 2, 2018

    thanks for this explanation, for me it’s very strange when I start wmic the appid value is differente that the appid value check by netsh. Ans I can’t retrive the netsh appid value into regedit. does you have any id ?

    Reply
    • George Spiers

      February 2, 2018

      You can delete it using “netsh http delete sslcert ipport=x.x.x.x:443” and replace it with your Broker Service SSL binding.

      Reply
  • Omar

    March 5, 2018

    I get this message “there are no apps or desktops available at this time” on my storefront site. This is only fixed when I change my option from HTTPS to HTTP under Delivery Controller as shown above. Here’s my private setup. I’ve some internal domain xxxx.local with storefront and delivery controller setup on different servers. Installed Active directory cert services with cert web enrollment on domain controller, created a cert request on my storefront server, then from cert web enrollment on domain controller, received ssl cert, complete the request by adding that ssl cert to storefront server under IIS, bind it to HTTPS on 443, then export that cert and import it over to delivery controller and my windows 10 client. Tested out citrix webstore on w10 client with https but still get security warnings, which means internal ssl cert i created not working properly. Did i not setup it up properly or am i doing something wrong? is it even possible to run https site on internal domain. Also, i don’t want to make that http change from https that fix my error mentioned in first line? Sorry for the long description.

    Reply
    • George Spiers

      March 5, 2018

      Yes you can use HTTPS internally. It sounds like the certificate you issued to your Delivery Controllers is not trusted from StoreFront servers or your W10 client. You need to make sure that the Root CA certificate is added to the Root Certificates store on all your domain joined clients/servers.

      Reply
      • Omar

        March 5, 2018

        First, I had added them to the Root Certificates store on my w10 client and two servers which runs delivery controller and storefront but still continue to get security warning on the browser. Then did a little bit research and came across an article which says to put into Personal store, tried that too and same issue. I read articles and watch videos where people are easily able to add internal ssl cert and run it without getting any errors, I followed the same steps and still get those security warnings. It just driving me crazy when I know that i’m doing it correctly. Does it matter whether the cert was issued from the storefront or should it be from delivery controller? Any suggestion. Thanks

        Reply
        • George Spiers

          March 6, 2018

          Does the Subject name of the certificate match the FQDN name you use to access StoreFront?

          If your clients trust the issuer of the certificate (Root CA) and you are accessing a URL that matched the certificate subject name then there should be no certificate warnings.

          Reply
          • Omar

            March 8, 2018

            Are you referring to Common Name of the cert as Subject Name? If that’s what u mean, then it does matches the FQDN of the storefront.

          • George Spiers

            March 8, 2018

            Yes so long as it matches the FQDN and your clients trust the issuer of that certificate you should not be getting any certificate warnings via the browser. Also make sure that your certificate is SHA2 and not SHA1.

  • Omar

    March 9, 2018

    My cert is SHA2. I’ll re-do the whole thing. Can you please just reply to the following questions, so I can do it properly. I been watching videos and followed lot of articles on how to create ssl cert for internal domain but none of them have worked as most of them tells different ways. Okay, so here are the questions.
    1) Which one should I pick from IIS to create ssl certificate? Create Certificate Request, Create Domain Certificate Request or Create Self-Signed Certificate for my .local domain?
    2) Where the cert suppose to be placed? Trusted Root Certificate Folder or Personal Folder. Just so you know, today, I tried with option “Create Domain Certificate” and it placed the certificate under “Personal Folder” by default
    3) What server should I create or request the certificate on? You know my setup already. Delivery Controller and StoreFront are on a separate server and I got one Domain Controller with Certificate Authority installed on it.
    4) Will I need to export the certificate onto other servers and a client machine? Is there a way to have one certificate that just applied to my client machine, delivery controller and storefront?
    5) Can you provide a best link to a tutorial that shows the proper way to get the SSL installed?

    Don’t know if I miss out on anything else that I need to ask you but so far that’s all I want to know. Thanks for your help.

    Reply
    • George Spiers

      March 9, 2018

      From IIS you use “Create Certificate Request”. Use a keysize of 2048 bits and make sure the Common Name matches the FQDN of your Delivery Controller load balanced address.
      Then submit the CSR to your Certificate Authority, use the Web Server template during certificate generation (I duplicate it and normally change some settings to suit).

      Once you have an issued certificate return to IIS on your StoreFront server and click “Complete certificate request”, export the certificate (including private key) and install the certificate to each DDC in the Computers Personal store.
      Now use the above netsh commands to bind the certificate to the Broker Service.

      Make sure within the Trusted Root Certificate store of your StoreFront and Delivery Controllers, they have the Root CA Certificate you created when configuring ADCS.

      Reply
  • Omar

    March 9, 2018

    I’ve been creating certificate request from storefront using the FQDN of the storefront as a common name and not of my delivery controller. This is new to me that the common name has to be the FQDN of my delivery controller when creating certificate request from storefront IIS. Load balancing is out of question here since I only have one delivery controller.

    Another thing, you said to install the certificate to each DDC in the computers personal store. Do you mean “Personal Store or Trusted Root Certificate Store? This is important to know because I remember you mentioned to me last time that the certificate should be in Trusted Root certificate store and not personal store.

    I’ll try as you say after you let me know where exactly I need to place the certificate on the computers. Thanks

    Reply
    • George Spiers

      March 9, 2018

      Sorry but this article is about securing XML DDC communication, and in your first comment you indicate that you have multiple Delivery Controllers by saying “delivery controller setup on different servers”.

      If you have multiple StoreFront servers and they are load balanced, create a certificate against the load balanced FQDN and install that certificate on each StoreFront server in the PERSONAL store. The Root certificate is installed on the Trusted Root Certificate Authorities store on each domain member server.

      Reply
  • Omar

    March 9, 2018

    sorry for the typo, but I meant to say that ddc and storefront are on different servers, so I’ve only one ddc, one storefront setup on a separate server. with this setup that I’ve, what would you suggest in terms of creating and configuring ssl properly? Thanks

    Reply
    • George Spiers

      March 9, 2018

      If you’ve just one StoreFront server then request a certificate for that server based on the FQDN. Then install the certificate on the StoreFront server’s personal computer store.
      Providing connecting clients trust the issuer (the root CA), it will trust the certificate and no errors will be shown.

      Reply
  • Omar

    March 9, 2018

    k, i’ll give it a try again but i did exactly the same before as you suggested, but i still wasn’t able to make it work. What should’ve been so simple with all the videos and articles around, it became more harder to configure for some reason. I’ll get back with the results. Thanks for all your help.

    Reply
  • Omar

    March 10, 2018

    George,

    Have you come across an issue with chrome not showing self assigned certificate under its “Trusted Root Certificate Authorities”? On my windows 10 client, I placed my cert into “Trusted Root Store”. Then I went into my Chrome Manage certificate settings to confirm its presence under “Trusted Root Certificate Authorities” but it’s not there. Even I imported it manually in Chrome, it says import successful in the end, but it still doesn’t show in there. Any idea why is that?

    Reply
    • George Spiers

      March 10, 2018

      I haven’t but what certificate did you import in to the Trusted Root Certificate Authorities store? It should be the Root CA cert. The StoreFront cert goes in to the personal store.

      Reply
  • Omar

    March 10, 2018

    Imported the cert I created in my storefront server, placed that cert into “Trusted Root Cert Authorities” on my DDC, Storefront and Windows 10 client. My Root CA cert already exist in all of them under “Trusted Root Cert Authorities”. On Window 10, open up internet explorer to my web receiver URL, received an error “Cannot complete your request” as soon as the Citrix receiver installed. Checked events log on storefront, found Events ID 15 and 17 with error “Failed to Run Discovery” which points to SSL certificate failure after doing some research online.

    I received “cannot complete your request” error on all the browsers I tried, chrome, internet explorer and Edge. I then thought that maybe because I placed my cert in the “Trusted Root Certificate Authorities store, I’m getting this error, so I moved my cert into “Personal store” as you had suggested, still the same. One thing I want to point out, I don’t get any security warnings on my internet explorer and Edge with my cert, just the error I mentioned. I do see a padlock on both browser which means the cert is trusted. In Chrome, I do get security warnings and I found out why. Chrome doesn’t accept internal CA cert with the common name anymore and instead it accepts with the ALT Subject name, so unless you have that you’ll receive security warnings in it.

    my cert is bind to https on my storefront and delivery controller, so I don’t know what the hell is wrong with my cert. The common name is same as my storefront server FQDN.

    Let me know if you got anymore suggestions for me or work around this problem. Have to say, this has been a pain my neck for the last 2-3 weeks now trying to figure out this SSL cert internally.

    Reply
  • Omar

    March 10, 2018

    finally, I got to make the SSL cert work but now I receive an error “there are no apps and desktops available to you at this time” which is exactly same as the main post. My storefront event logs showing an error “None of the Citrix XML services configured for farm controller are in the list of active services, so none were contacted”. On my delivery controller, I don’t see any Citrix XML Services running, it’s not even showing under my Services control manager. How do i fix this?

    Reply
    • George Spiers

      March 11, 2018

      Have you added a Delivery Controller to your store on StoreFront and if so, are you using HTTP/80 communication for XML services? If using HTTPS you have to follow this guide.

      Reply
  • Omar

    March 11, 2018

    Yes, my deliver controller has been added to my store on storefront since day one. I’m using HTPS as Transport type for XML services under Manager Delivery Controller option on storefront.

    The issue is my Citrix XML service is missing on delivery controller and this was due to the IIS that was on my delivery controller. I’ve uninstalled it now, but your guide doesn’t show how to install or enable Citrix XML Services and I can’t find anything online that shows me how to make it appear on delivery controller. I ran brokerservice /show command on delivery controller to see what services and ports were running. Here is the result..

    C:\Program Files\Citrix\Broker\Service>brokerservice /show
    SDK Port: 80
    VDA Port: 80
    StoreFront Port: 80
    StoreFront TLS Port: 443
    Log File:

    FYI – There is a temp solution to overcome the error I’m receiving if i change Transport Type to HTTP from HTTPS, but I want the communication to be secure over HTTPS.

    let me know what else I can try. Thanks

    Reply
  • Omar

    March 12, 2018

    Did a little bit more research and found that Citrix XML Service is built into Broker Service. So, I followed your guide above to bind the SSL cert to 443 on delivery controller with certhash and guid. SSl cert was successfully added and verified using http show sslcert, but I’m still getting “There are no apps and desktops available at this time” including the other error that i shared above about xml service configured from the events log.

    One thing i did different is that the Citrix Broker GUID key i pulled it from the registry editor and not through the command prompt as you did. I noticed when I run the command to get the APPGUID, it was different from the one i pulled from the registry editor, so i went with the registry editor.

    Do you think this might be why I’m still seeing the errors or do i need to reboot my storefront and delivery controller servers in order for changes to take effect?

    Thanks

    Reply
    • George Spiers

      March 12, 2018

      No need to reboot servers. From where in the registry are you finding the AppGUID? Use the value that is returned in command prompt.

      So long as you use the correct GUID, the certificate is trusted and matches the FQDN of Delivery Controller as specified in StoreFront then it should work.

      Reply
  • Omar

    March 12, 2018

    Followed link below to find the AppGUID in the registry https://support.citrix.com/article/CTX200415

    As far as the cert goes, it was created on storefront server with its FQDN and then exported it out to the delivery controller and Windows 10 machine. My cert seems trusted as I don’t get any security warning errors like I used to get either in IE or Edge as I explained in my previous posts. So, my delivery controller has a cert with storefront FQDN as my other machine does.

    Are you saying that I’ll have to create another cert with delivery controller FQDN to make this work? If I do, what do I suppose to do with my other cert that delivery controller has? Do I leave it in there or remove it once new one is created? Also, Will I need to export the new cert from delivery controller to my storefront server and windows 10 machine? My current cert is placed under “Personal Store”, Is that where I be placing it again?

    This is all so confusing to me, I thought u only need one cert that I created on storefront and share that with all other machines and that should be it.

    Thanks

    Reply
    • George Spiers

      March 12, 2018

      You need a new certificate which matches the Delivery Controller load balanced FQDN address. If you have just one Delivery Controller, or two not in a load balanced configuration then you will need certificates for each one matching the FQDNs of each server.

      You need to remove the existing netsh binding, and then add a new binding using the steps from this guide to bind the Citrix Broker Service to the new certificates.

      Also, the certificate goes in to the Personal computer store of each Delivery Controller. It does not have to be imported to any other server.

      Reply
  • Omar

    March 12, 2018

    Understood. Just one thing if can answer which I asked before, do I need to remove my other SSL cert that was created on storefront server and distributed to my Windows 10 and Delivery controller? Should I remove it completely from everywhere?

    Reply
  • Omar

    March 13, 2018

    George,

    Thanks for all your help. I was able to fix my errors and now my desktops and apps shows up in my browser. Sorry to bother your throughout my issues for help and appreciate for taking a time out and replying to all my comments. I would like to leave few questions here for better understanding and a knowledge on SSL cert. Whenever you have time. No RUSH. These are as follows.

    1) Is it true that only the root cert needs to be distributed to the clients? This I was told by Citrix expert on another forum who helped me in my issues.
    2) Is the following scenario or condition correct In order to gain access to Desktops and Apps over HTTPs as far as the SSL cert goes?
    Storefront server only need ROOT CA and not any other cert.
    Any Windows client only need ROOT CA and not any other cert
    Delivery Controller must have SSL cert with its FQDN and ROOT cert
    3) If the above condition or scenario is not correct, what certs will I need on what machines?
    This I’m asking from SSL point of view and not any other changes that I know are required on storefront server in order to have the secure communication between Delivery Controller and Storefront server.

    I wouldn’t have asked you If I remember what I did to overcome all my issues on SSL since past 3 weeks.

    Thanks

    Reply
    • George Spiers

      March 13, 2018

      No problem.
      1) Yes the Root cert needs to be distribured to all domain clients and domain member servers.
      2) StoreFront needs the Root CA (as per question one) and a specific SSL certificate matching the SF FQDN for clients connecting to StoreFront over HTTPS. All windows domain clinets need the root cert and no other certificate. DDC like StoreFront for HTTPS XML communication must have a cert matching the DDC FQDN and a root cert.
      3) See answer one and two

      Reply
  • Omar

    March 13, 2018

    I’m confused over one thing if you can clarify. In your reply 2nd reply, you said that All windows domain clients need the root cert only as the other Citrix guy said.

    So, I access Citrix Web Receiver URL from Desktops and Apps from my Windows 10 client always, and If the windows domain client only has Root CA and not any other cert like Storefront Server FQDN cert, how my client would then communicate over HTTPS with the storefront server which has Citrix Web Receiver residing. Wouldn’t it throw up security warnings errors?

    Thanks

    Reply
    • George Spiers

      March 14, 2018

      Because when your client contacts StoreFront the machines perform an SSL handshake, with the StoreFront server identifying itself by using the StoreFront certificate. Since the Windows 10 client has the Root CA Cert in it’s Trusted Root Certificates store, it is able to trust the certificate StoreFront is presenting and no SSL/security warnings are flagged.

      Reply
  • Omar

    March 15, 2018

    Got it. Learned a great deal from you. Thanks again for all the help.

    Reply
  • Ray

    March 27, 2018

    I have director on both Ddcs with a ssl already. In order to do the https transport mode. I assume I’m going to have to change the port that it will listen to now if I want to use ssl from my ddc to storefront.

    I am guessing here

    Reply
    • George Spiers

      March 27, 2018

      Both can use 443, just bind the certificate to the HTTPS binding in IIS.

      Reply
  • Ray

    May 3, 2018

    Hey I really appreciate your help sir. Thanks you

    Reply
  • Mark Dear

    May 14, 2018

    This is an excellent article and proved very useful. I used this to script the process via Powershell. Many thanks

    Reply
  • Ron

    June 28, 2018

    Hey, i did it everything goes good but i dont get application and get event “none of the citrix xml services configured for farm controller are in the list of active services, so none were contacted”
    am i missing something?

    Reply
    • George Spiers

      June 28, 2018

      Have you configured StoreFront stores so that the Delivery Controller port and transport type is set to 443/HTTPS? Also make sure to propagate these changes to your remaining StoreFront servers.

      Reply
  • SH

    August 14, 2018

    Hello, We have requirement to setup Secure XML communication.
    Currently its configured : DDC are load balanced on NetScaler. (Only VIP of DDC has been added in storefront)
    DDC LB VIP is using HTTP.
    No DNS is assigned to VIP
    No IIS installed on DDC.
    Do i need to install certificate on each DDC and bind the cerificate to each broker service using netsh command or this step is not required. Kindly suggest
    Else How we can achieve this ?

    Reply
    • George Spiers

      August 14, 2018

      Yes you can follow this guide to bind each certificate to the Citrix Broker Service via netsh.

      Reply
      • SH

        August 27, 2018

        Thanks George. If same DDC’s are used as STA on gateway settings, Do we need to change the STA to “http://x.x.x.x/Scripts/ctxsta.dll –> https://x.x.x.x/Scripts/ctxsta.dll” on both NetScaler and Storefront. Kindly suggest

        Reply
        • George Spiers

          August 28, 2018

          NetScaler and StoreFront must be configured with the same STA list, yes.

          Reply
          • SH

            August 28, 2018

            George, my question here is, Is it mandatory to change STA as HTTPS once we enabled secure xml communication? or does it work in http as well though DDC’s secure https communication.
            STA = DDC IP Address.
            Thanks

          • George Spiers

            August 29, 2018

            No, it can work via HTTP also, so it is not mandatory to change.

  • Tom

    August 22, 2018

    Hi George – I am working with a customer currently that does not have an internal CA and doesn’t own their internal domain name. Is there any way for them to secure XML traffic in this case?

    Thanks!

    Reply
    • George Spiers

      August 22, 2018

      You could use an external certificate in that case that matches an FQDN that StoreFront would then use to reach the Delivery Controllers.

      Reply
  • Pingback: Load Balancing Citrix Delivery Controllers with NetScaler – JGSpiers.com

  • Anonymous

    January 17, 2019

    Hi George, Great article as always. What are the advantages of setting up load balance at the StoreFront vs. at the NetScaler for the DDC’s? What LB method does StoreFront use when load balancing the DDC’s?

    Reply
    • George Spiers

      January 25, 2019

      A lot of people just load balance DDCs via StoreFront now as it reduces complexity. One thing NetScaler is good at doing is monitoring the DDCs, using the pre-built monitor. You can also add weights to servers to one receives more requests than the other. Other than that there is no reason to load balance the traffic via NetScaler. Not 100% sure that method is used, I believe it is Round Robin. Some WireShark traces would confirm!

      Reply
  • RJS

    February 5, 2019

    Hi JG

    Whats the best way of tackling this if your Storefront and Delivery Controllers are all on the same server and some servers also including one Director role.

    This environment has delivery controllers/storefront servers loadbalanced in the same VIP and storefront is only https and the managed delivery controllers are currently http in storefront settings. Is it just the case flipping it to https and ensuring fqdn has the xdc fqdn and not the load balanced vip.. its a bit confusing as both roles are on same server so not sure how to approach.

    Reply
    • George Spiers

      February 7, 2019

      Watch out for port conflicts. If StoreFront or Director is also listening on 443 then you will have problems. If they are all port 80 and the VIP is 443 (SSL offloading) then you should be able to take the approach you mentioned.

      Reply
  • Manuel

    February 11, 2019

    Thanks a lot for this blog post and all the others too. Love your work.

    Just wanted to comment that the WMIC product property we are after is the IdentifyingNumber, and that the query below can help get the correct id without so much verbose..

    wmic product where “name like ‘Citrix Broker Service'” get caption, identifyingnumber

    Reply
    • George Spiers

      February 12, 2019

      Even better – I’ve updated the article to include this command. Thanks.

      Reply
  • Datta

    February 3, 2020

    is it mandatory to have PFX format certificate only on the DDC’s? We have the generate a CSR and provide the code to CA team to provide the certificate, in this case how do I create a certificate as PFX format? is there any way to create CSR with reference to PFX?

    Reply
    • George Spiers

      May 10, 2020

      Do you mean to export it to the other servers? After receiving the certificate back from your CA team and installing it on a Delivery Controller, you could export the certificate and private key to the remaining servers.

      Reply
  • Anonymous

    March 4, 2020

    When i type wmic product where “name like ‘Citrix Broker Service’” get caption, identifyingnumber

    i get error like invalid alias verb

    Reply
  • ohlssrog

    March 6, 2020

    When i run wmic product where “name like ‘Citrix Broker Service'” get caption, identifyingnumber
    I get error
    Node – servername
    ERROR:
    Description = Invalid query

    Reply
  • SH

    May 28, 2020

    Hello George, We have already configured Secure XML communication in our environment. Now, certificate is going expire soon. So we need to install new certificate on DDC. What are steps we need to follow and what precaution we need to take so that it should not impact current production environment.
    Thanks
    Shashi

    Reply
  • Fred L.

    November 4, 2021

    Thx for the share George ! It works !

    Reply
  • ohlssrog

    March 3, 2022

    Hi. We have just update our wildcard certificate that are used in our virtal apps setup and have follow ur instructions, but after we have update the cert no published applications are showing up. If we set the Store on http in transport type instead of https it woks fine.

    Reply
  • Imran Khan

    June 17, 2022

    Hi George,

    Amazingly I went through each and every person word and look at your article up to the mark. I have generated the CERTIFICAT
    1. Have root cert
    2. Have IIS cert Binding in HTTPS port 443
    Went through the binding but it is still not working after enabling the HTTPS option on the Manager Delivery controller. It does not showing the app when on HTTPS but did showing when on HTTP.

    Even CITRIX called CITRIX as well but they are not able to find anything yet and again asked to give time.
    I have 4x Delivery Controller and 4x Storefront server each of the server have both APPS are on the 4x servers like 2x each on the server.
    I am wondering if XML service is using the HTTPS and that is not enabled so the connection between the Storefront and Delivery controller not secure and the Username / password will pass through in clear taxt..

    Can you please advsie in details. Thanks for the brilliant and fab article on this.
    Oma

    Reply
  • Rick

    September 29, 2022

    Hi JG,

    If the delivery controllers are not load-balanced behind a NS LBVIP, can I just do IIS and have server fqdn certificate (e.g. ddc01.company.org an ddc02.company.org) and bind the certificate, then match it in netscaler and STA config on Storefront and change manage delivery controller to https?

    Reply
  • George

    November 1, 2022

    Hello George, great article, Is this configuration same for Cloud Connectors for Citrix DaaS with on-prem Storefront?

    Reply
    • Anonymous

      January 23, 2024

      Yes it is the same. This write-up helped me for that exactly

      Reply

Leave a Reply to George Spiers Cancel reply