Deployment and Imaging Group

 View Only
  • 1.  Auto Deployment stuck at "Client Record Updated"

    Posted Jun 22, 2018 05:26 PM

    I'm not sure where to start, but I'm running a distribute disk image job against a machine.  PC reboots, connects to PXE, boots to WinPE, loads drivers successfully, and establishes a network connection.  Then it starts dagent.  Dagent displays "client record updated" but that is where it stops.  It shows the address for my server, it shows the address for the client, but it doesn't display computer name or MAC address.

    I'd like to troubleshoot why it hangs.  Are there logs I can create that can assist here?  Any advice or tips would be appreciated.  I'm running a trial version of GSS 3.2 trying to get a proof of concept going so we can evaluate this product.  

     

     



  • 2.  RE: Auto Deployment stuck at "Client Record Updated"

    Posted Jun 23, 2018 02:28 PM

    Hi MIchael,

     

    Might not necessarily be the same issue, but check at the advice given to the OP:

    https://www.symantec.com/connect/forums/winpe-hangs-client-record-updated

    Thanks!



  • 3.  RE: Auto Deployment stuck at "Client Record Updated"

    Posted Jun 23, 2018 07:17 PM

    Hey Michael,

    Based on some troubleshooting I provided in a different thread, I think your issue may be the ADK you used to create the WinPE environment.  If you are using the latest ADK available which at this time happens to be ADK for Widows 10 1803, I believe that is your issue.  The highest supported build of the ADK that Ghost Solution Suite supports at this time is 1709.  To remedy this situation, I would delete any jobs referencing the WinPE environment...that will free up the WinPE environment in the PXE utility so that it is no longer "In use." Next, delete the 1803 WinPE from the PXE Utility.  Once you have deleted the WinPE, I would uninstall ADK 1803 and reboot for good measure.  Finally install ADK 1709 and rebuild your WinPE, and if you chose to delete the jobs, recreate those now referencing the 1709 WinPE.  Hopefully this gets you further along but if it doesn't, please respond with your findings.  If this happens to solve your issue, would you kindly mark this as a solution?  Thanks :)

     



  • 4.  RE: Auto Deployment stuck at "Client Record Updated"

    Posted Jun 27, 2018 12:48 PM

    Thanks for the reply Joel.  I saw the thread you were referring too, and have already uninstalled ADK 1803 for 1709.  I've also rebuilt my WinPE and jobs.  The only thing I may have done differently is I don't believe I rebooted after uninstalling 1803.  Let me give it another try and I'll report back.



  • 5.  RE: Auto Deployment stuck at "Client Record Updated"

    Posted Jun 28, 2018 09:10 AM

    Hey Michael,

    It just occurred to me that you may have a couple of console based settings that are causing you this grief.  When a system boots to WinPE, the natural behavior is that it will react one of two ways.  If the system is unknown to the database (does not have a record), it will stop in WinPE and go into a wait state.  The icon associated with the “Wait” state in the console is a yellow triangle over the computer icon.  If it is known to the database (has a valid record), the other way it behaves is that it will simply check if there is a job pending for it, and if so, execute that job, if there is no job pending for it, then it will simply reboot back to production. 

    Forgive me if you already know this, but the reason I bring it up is that you may be suffering from a breakdown in the first scenario. Things that have thrown me for a loop in the past are the global identifiers [ Tools > Options > Global Tab ] in the global settings.  There is where you specify the criteria for identifying a system.  By default, this criteria is only the MAC address, and so you may see where I am going with this.  Because it only uses the MAC address as the only identifier, things like docking stations, port replicators, usb dongles, and wireless adapters would all have different MAC Addresses than the internal LAN adapter, and could inadvertently result in a duplicate record because GSS thinks it is in fact a completely different system.  Using a dongle and such across multiple systems would result in this kind of thing if you haven’t changed the global identifiers.  

    If by chance you ended up with a duplicate record in the database, it might explain you scheduling the job against a stale or invalid record and it might explain why the jobs are not kicking off.  Another global setting that is not checked by default is the “Synchronize display names with computer names” option [ 3rd checkbox from the top on the same Global Tab].  This setting refreshes the record name to whatever it is on the running operating system.  This setting is not as important in WinPE because it normally resolves to its production name, but if it was a new system that had not been managed it would show up usually as the serial number of the system.  If the box is unchecked it could be confusing if its just not updating the record to reflect the system correctly in the console.  Anyway the way to fix all this is to add an additional global identifier such as the serial number.  That way when a new record is written to the database, it will see the new MAC address, but then match it to the serial number of an existing record and not create an additional record. 

    It is important to know that the system will not retroactively merge records, so if this is in fact your issue, the best thing to do would be to look in the console and confirm you do not have any duplicates for the system in question.  The global identifiers can also work against you if you are dealing with a system board that has been replaced but not branded properly. An example of this is a system that has a UUID of all zeros, or a serial number that has not been set such as NULL.  This would also cause duplicates in the database since GSS would not be able to resolve unique values for the records.  Sorry this post is so long winded, but even if this is not your issue, it may help someone else.  I hope this gets you further along.  If it happens to solve your issue, would you kindly mark it as a solution.  Please report back with your findings.

    Thanks! Good Luck :)



  • 6.  RE: Auto Deployment stuck at "Client Record Updated"
    Best Answer

    Posted Jun 29, 2018 07:06 PM

    This is resolved.  Back when I was using GSS 2.0 I was able to run it off a desktop.  I realized that GSS 3.2 really works better on Server.  I rebuilt my server on 2012 R2 and everything is working fine.  

    I should have mentioned this key piece of information in the beginning, but I do appreciate the help fellas.  



  • 7.  RE: Auto Deployment stuck at "Client Record Updated"

    Posted Jun 29, 2018 07:08 PM

    By the way, I was previously using Win 10 Ent.  Another difference is I enabled RDP on the client which I didn't realize was turned off.  It could have been that too.



  • 8.  RE: Auto Deployment stuck at "Client Record Updated"

    Posted Jul 03, 2018 02:51 PM

    Ah, great glad you got it solved.  Just for the sake of others, would you mind marking your answer as the solution to the issue?  Thanks :)