We use CMS to image new machines. We have gotten in a few Dell laptops (like 5290) that don't have built in Ethernet and I use a USBC dongle to image them. I use the same procedure I use for any other desktop or laptop, get it to iPxe, pick image job, then it reboots to production where it should finish installing some software. Works great for regular desktops and laptops.
For clients without built in Ethernet with these dongles, I get duplicate records in CMS where there is a record in PXE and a record for when machine comes out of PXE. The problem is the job I chose in PXE deploys the image and reboots to production, but then the client never gets the rest of the job because it's a whole new record that has no history of the job running. The original job eventually fails because it thinks it never did reboot to production.
After talking to support, it seems like this is a known issue since NICs are used as primary identifier and in PXE it has 1 NIC (from USBC) and as soon as machine boots, it has a different "fingerprint" because it has USBC NIC + wireless NICs.
I know I could have 1 image job and then a post image task job, but that's a pain for techs, not to mention to then ask techs to delete the "bad" record.
Anyone have created workaround for the issue? I can't imagine managing a few hundred of these machines as is. As machines get smaller and dongles more popular, I'd hope Symantec has an answer for this coming soon.
Anyone affected by this, I'd encourage you to put a ticket in and also subscribe to this etrack
I'm seeing the same issue with the Dell Latitude 5290 2-in-1 hooked up to the Dell WD15 USB-C docking station. Even when leaving the 5290 plugged into the dock at all times, the computer is associated with one record when imaging in WinPE, and associated with a different duplicate record once it boots into Windows. It's interesting to note that this problem does not occur when using the WD15 dock with our Precision 7530 laptops, but that may be because the 7530 does have an onboard NIC.
Changing the primary lookup key could possibly resolve this issue. You can change this in the settings. Attached is a screenshot.
Full disclosure though, this is a pretty big change so make sure this is what you want before changing it.
I heard they're close to fixing this issue, but not sure what that means in terms of timeline.
You may want to add the MAC address of the dongle to the "InvalidMacAddress" setting in the CoreSettings.Config file. This will prevent the NS from using the MAC address as a unique identifier when determining whether or not the computer is a new or existing record. Option 2 in this article explains how to add a value to the InvalidMacAddress setting...
The article is specific to the merging of records of computers running in VMWare and Parallels , but the steps should work for this issue.
We have this issue with the Dell Precision 5530 devices. I have had greater success by setting "MAC Address Pass-Through" to "Disabled" in the BIOS. When that is set to 'disabled', the GUID in WinPE and the GUID in Windows matches. When it is set to "Passthrough MAC Address", the failure rate is much higher (near 100%). Not all our Dell devices have this option so I don't know if yours will or not...we don't have that model in our stock.
It might be worth trying.
For HP x360 1030/40 family I have found using the usb c dongle that comes with them and turning fast boot off in the bios will fix it
FYI issue reportedly fixed in 8.5 RU2 and 8.1 PostRU7 - looking forward to testing.
I'd hold off on installing RU2 if you image with it. It's now creating duplicate records every time I reimage a machine (even with build in ethernet). Will report back what the recommendation is (ugh).
Thanks sally, going to cancel our upgrade since we have a solid month of no imaging issues and have urge to have it break now
Hi everyone. I'm the Sr <pwa class="pwa-mark pwa-mark-done pwa-unused" data-pwa-category="spelling" data-pwa-dictionary-word="Backline" data-pwa-hint="Unknown word: Backline" data-pwa-id="pwa-8D120FAC0D47DA9D3F08733E14A3E9E2" data-pwa-rule-id="SIMPLE_SPELLING" data-pwa-suggestions="Backlin~Jackline~Backlinie~Blackline~backbone">Backline</pwa> support engineer for DS. The new process works by writing a registry key named '<pwa class="pwa-mark pwa-mark-done pwa-unused" data-pwa-category="spelling" data-pwa-dictionary-word="DSUniqueID" data-pwa-hint="Unknown word: DSUniqueID" data-pwa-id="pwa-12A565DA65D5D5AD78D80A5B145D7951" data-pwa-rule-id="SIMPLE_SPELLING" data-pwa-suggestions="Disunited">DSUniqueID</pwa>' to the production registry while in automation and then checking for that value once back in production.
Yesterday we had a customer whose production registry became 'locked' and our automation agent couldn't read the key; hence a record <pwa class="pwa-mark pwa-mark-done" data-pwa-category="style" data-pwa-dictionary-word="was created" data-pwa-hint="Passive verbs make your writing less direct. Try to use an active verb instead." data-pwa-id="pwa-005326FA4FA18BC78E27A6E22D7CC947" data-pwa-rule-id="null" data-pwa-suggestions="">was created</pwa>. Once we unloaded and reloaded the registry hive, the query worked. We are not sure why the production registry periodically locks.
Please create a support case describing the situation and make sure you note this occurs after upgrading to RU2.
Note: This isn't an across the board issue. The fix has had extensive testing.
-<pwa class="pwa-mark pwa-mark-done" data-pwa-category="spelling" data-pwa-dictionary-word="doug" data-pwa-hint="Unknown word: doug" data-pwa-id="pwa-2CA3364F56D343BAA3C6E8C3BDE9C4DF" data-pwa-rule-id="SIMPLE_SPELLING" data-pwa-suggestions="dog~drug~dug~doux~dough">doug</pwa>
This is one of our biggest headaches with most laptops no longer coming with built-in nics. Our school district is about to order almost 2,000 new laptops and we'll only be using about 60 USB nics. I miss Altiris 6.9 when the unique identifer was the serial number.
Using 8.1 RU7 currently.
Bother. I wish I'd seen @ Sally5432 's comment about duplicate records before installing RU2! We're seeing them now just for ordinary machines with built-in NICs. @doughchicken - is this a known issue yet or an unknown issue?