Jump to content
Welcome to our new Citrix community!
  • 0

Citrix XML Service missing


Omar Mian

Question

Hi,

 

I'm receiving an error "There are no apps and desktops available to you this time". Checked the event logs on my storefront server and came across error ID 4012 "None of the Citrix XML Services configured for the farm controller are in the list of active services, so none were contacted". On my delivery controller, I ran brokerservice.exe /show and I got the following:

 

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

 

my Citrix XML service no where to be found under Services Control Manager. This I found out that it was due to the IIS installed on my delivery controller since they shared the same port 80. I've now uninstalled it and would need help in installing and configuring XML service in order to fix the above error.

 

Can someone help me?

 

Thanks

 

Link to comment

12 answers to this question

Recommended Posts

  • 1

Is StoreFront complaining about certificate trust issues?

 

In StoreFront Console > Store > Manage Delivery Controllers, did you add them using FQDN? Does the certificate on the Controllers match the FQDN? Are the certificates trusted by StoreFront? StoreFront Event Viewer should indicate this.

 

There is no need to change the port numbers for the XML Service. Once you bind a cert, it automatically listens on 443.

  • Like 1
Link to comment
  • 0

Carl,

 

I want the communication to be on https since my cert is already in place. I've seen this temp solution before that you suggested.

 

Is there a way to keep the Transport type to HTTPs and still be able to get rid of the error above in my original post? 

 

My main issue is to get the XML service registered and running which I can't find how to do it anywhere? If you can help me with that, I think I'll be able to do the rest myself.

 

Thanks

 

 

Link to comment
  • 0

k, I followed the link you provided, was successfully able to bind ssl cert to my delivery controller, but I'm still getting those 2 errors I shared above. 

 

I came across another article which shows how to bind the XML services to 443 on delivery controller but one thing he did differently is that he used command prompt to find the Citrix Broker service GUID instead doing it via Registry Editor as shown in your link above. I looked up for the GUID both via Registry Editor and the command prompt, and I found it weird that the Citrix Broker GUID doesn't match in the command prompt and registry editor, this was confusing so I went with the registry editor and pulled it from there. 

 

Do you think the 2 errors i'm still getting might be because of the Citrix broker GUID or do I need to reboot my storefront and delivery controller servers in order for changes to take effect? 

Link to comment
  • 0

My storefront doesn't complain about certificate issues.

 

I do have delivery controller added with its FQDN in storefront console under Manage Delivery Controllers. You asked if my cert on the controllers match the FQDN, my cert doesn't matches the FQDN of the delivery controller. So, here is a little bit of background on the cert that I created.

 

My cert was created on storefront server with its FQDN, bind it to the IIS on port 443. Then exported it out to my delivery controller and Windows 10 client. So, I've two certs, one that I created on storefront with its FQDN and the CA root internal cert. CA root cert is placed under Trust Root Authorities Store on all the servers and Client and the cert with storefront FQDN is placed under Personal store on all the servers and client.

 

All my certs are trusted as I don't get any security warnings on any of the servers and client using either IE or Edge. I can access my storefront Citrix web URL for apps and desktops without any warnings or errors with https. My base URL matches with the FQDN of the storefront server.

 

Going back to your question on "Does the certificate on the controllers match the FQDN? Are you saying that I need to have a cert with delivery controller FQDN on the controller itself? If you do, I've then few questions?

1) What happen to my other cert that I created with storefront server FQDN and share with other servers and client? Do I remove it or leave it in there?

2) Once another new one is created with delivery controller FQDN, will I need to export it out to my other servers and client like storefront and Windows 10 machine?

3) Where would I need to place that new cert? Do I place it under "Personal store' or "Trusted Root Certificate Authorities"?

 

I thought u only need one cert that I created on storefront and share that with all other machines and that should be it, but it seems not

 

Thanks

 

 

Link to comment
  • 0

Only the CA root cert needs to be distributed to client machines.

 

Yes, if you are using https between StoreFront and Controller, then the Controller's certificate needs to match the Controller's FQDN. The only "SSL client" for this SSL communication is the StoreFront server.

 

Or, change the Delivery Controller transport type to http and don't worry about Controller certificates.

Link to comment
  • 0

I would like to keep using https between storefront and controller.

 

This is something new to me that only CA root cert needs to be distributed to client machines. All the videos and articles I read suggested to distribute CA root and SSL cert to servers and client. 

 

So, now I know that a new cert with controller FQDN is required, should I remove my other ssl cert created on storefront server from controller, windows 10 client and a storefront server?

 

Also, should I create a new one on delivery controller and distribute it to storefront server?

 

 

 

 

Link to comment
  • 0

I'll do that but you didn't tell me what should I do with other ssl cert that are on delivery controller as well as storefront server. Should I remove it?

 

Do I need to export new cert from controller out to storefront server as well?

 

last thing, how does a cert created on controller trusted by storefront? Is it when controller FQDN is added to the storefront console under Manager delivery controllers or something else?

Link to comment
  • 0

Not sure if this helps but if using https you need the Storefront controllers tk be written in the same formatt as your cert. So your cert, if internal, is likely 5o be the FQDN of the DDC servers. Therefore your ckntrollers  use be written as the FQDN for it to talk on https. Something J see a bit when all the binding has been done.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...