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

MCS Created Windows 10 Machines Have Same Hostname as Master Image


Question

Despite completely rebuilding the Windows 10 master image from scratch and not only that, a different version of Windows 10 (LTSB), it keeps naming all the Windows 10 host names the exact same name as the master image machine.

 

Things to know:

 

1. XenDesktop 7.15

2. Windows 10 LTSB (2016)

3. Nutanix AHV 5.5

 

Things I have done:

 

1. Reinstall VDA using Autoselect.exe

2. Rebuild the image entirely.

3. Ensured KMS is functioning as it should with Windows and Office 2016.

4. Ensured DHCP is working fine, at least for the master image, but registers the duplicate Windows hostnames after creation, which is the problem.

 

What is going on here? Why does this happen? Nobody seems to have an answer on any posts about this same issue which has apparently been happening since XD 5.x.

 

 

Link to comment

25 answers to this question

Recommended Posts

  • 0

Okay, based upon that information I think we need to look at the identity disk.  IIRC MCS saves AD information that gets set on each reboot (since the machines are pooled and clear themselves each time) to the identity disk with the VM.  Can you check to see if this identity disk exists in your hypervisor?  I believe it should be 16MB.  I wonder if this disk did not get created or is not accessible when the machine boots and therefore it cannot apply the AD information.

Link to comment
  • 0

I only have one disk attached to the machine, I didn't realize and it's not mentioned anywhere that I needed two disks. Should I add another small disk to the master?

 

From reading the documentation and primer, apparently this additional disk is supposed to be automatic. I don't see any additional disks added automatically to these virtual machines that get created with the catalog.

Link to comment
  • 0

No, the smaller disk should be created automatically by MCS when you run through the process.  See the screenshot below from my environment.  Can you check your nutanix datastore and see if the identity disk was created.  If it is missing, this is why your machine information does not change.  Here is a good article from Citrix on how exactly MCS works: https://support.citrix.com/article/CTX218082 

 

image.thumb.png.a463e959983d4fd707a53d44820215b2.png

Link to comment
  • 0

I'm not sure how it is done in Nutanix but the question here is when or at what point does MCS create it? If I delete a catalog does the identity disk get deleted too? 

 

Short answer here is that I do not see the disk is being created on the individual machines that spin off the master image after creating a catalog. I see it in our older catalog machines, it's there, but that catalog was created way back in May of last year. Not sure what changed or why this identity disk stopped being created with the machines. It was definitely working last week and this started from the point when I recreated the machine catalog I created early last week.

Link to comment
  • 0

Something in the environment broke either on the Nutanix side (firmware update) or the Citrix side (DDC Upgrade?) that made it break. One thing you could try is to create a brand new "hosting" connection to your Nutanix.  Just give it all the same information but a different name and try to create a new catalog with the new connection.  I had something happen at another client awhile back where the permissions got messed up and recreating the connection fixed it. 

Link to comment
  • 0

Ok so the only thing that seems to work here is adding a small disk to the master image machine, formatting it in disk manager, and saving that snapshot.

 

I created a small, 10gb disk and added it to the master VM. I powered it up, I opened disk manager and formatted the disk. I shut down, I created a snapshot and then created a new catalog from that snapshot. The new catalog machines all have the same additional 10gb disk in addition to having the correctly renamed hostname. 

 

Can someone explain this crazy?

Link to comment
  • 0

Maybe in the past you had catalog deployment issues and have been playing with options @ https://www.citrix.com/blogs/2016/04/04/machine-creation-service-image-preparation-overview-and-fault-finding/  ? 

 

i.e. check if you have disabled and are bypassing the image preparation phase   

run >>   Get-ProvServiceConfigurationData

 

if nothing changed \ defaults etc... this will return empty 

but if changes made as per blog you might see an entry ... ImageManagementPrep_DoImagePreparation = False 

image.png.9224d1f0177fe757f925c62f0621a101.png

 

That will be what is causing the behaviors described in this thread. 

use the remove-prov..... to get rid of that entry 

 

as stated in the blog bypassing image prep should be considered only as a workaround... and i would add as a temporary one as much. 

 

 

Link to comment
  • 0
On 3/28/2018 at 2:33 AM, Nathan McKaskle1709158938 said:

Despite completely rebuilding the Windows 10 master image from scratch and not only that, a different version of Windows 10 (LTSB), it keeps naming all the Windows 10 host names the exact same name as the master image machine.

 

Things to know:

 

1. XenDesktop 7.15

2. Windows 10 LTSB (2016)

3. Nutanix AHV 5.5

 

Things I have done:

 

1. Reinstall VDA using Autoselect.exe

2. Rebuild the image entirely.

3. Ensured KMS is functioning as it should with Windows and Office 2016.

4. Ensured DHCP is working fine, at least for the master image, but registers the duplicate Windows hostnames after creation, which is the problem.

 

What is going on here? Why does this happen? Nobody seems to have an answer on any posts about this same issue which has apparently been happening since XD 5.x.

 

 

I know this is an old thread, but where did you get to on this in the end. I started having this exact issue after November 19 updates on my App Layering image using MCS. All machines get the same hostname (CITRXAL0) and domain trust is broken. All 16mb identity disks are correct. VDA is working just during the Update Image phase its not correctly setting the vm's machine name.

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...