all just properly reboot and exit the WinPE, but status in the ITMS still show "running" (which is not correct).
we really need to find the right exit code for this, in order to be able to automate another task to run after this completes successfully.
what is the right way to achieve a correct exit code status for a successful reboot from the WinPE?
Original Message:
Sent: 10-28-2020 08:14 AM
From: Hagai Nachmani
Subject: Boot WinPE (via PXE) fails on selective machines.
Hi Igor!,
Thank you for all the above, I am now back to the source issue:
the Boot to WinPE provides a false negative (status results are "failure" or "running", but task actually runs properly and successfully).
Since this isn't a custom script, I can't edit any "error flags" (due to it being an internal ITMS tool). here are some pictures to provide info:
Where can I find the "flag" (if such exist), or where can we identify by the error code what is needed to be done to resolve this. (the reason we want to know, it so we can rely on status reports).
Could it be that during "Boot WinPE" stage (when machine reboots into the WinPE), there is not visible indication from the device back to the ITMS, and that's why we can't get any status successful?
How can we make sure the status report of a task will be identical to the actual action is performs?
Thanks ,
Hagai
Original Message:
Sent: 10-26-2020 09:00 AM
From: Igor Perevozchikov
Subject: Boot WinPE (via PXE) fails on selective machines.
This is your choice whether you want to use a "Persistent Connection" functionality in your environment or not. You can turn it off if not needed to use.
"Persistent Connection" allows to immediatelly receive/execute tasks on client side & you can push policies from SMP Console to persistent connected computers.
------------------------------
Software QA Engineer
Broadcom Inc.
Original Message:
Sent: 10-26-2020 08:40 AM
From: Hagai Nachmani
Subject: Boot WinPE (via PXE) fails on selective machines.
Deployment Solution Plug-in - this was the root issue, once enabled on all windows machine, i am now able to run the Boot to WinPE task.
only question is, do i need all the "persistence connection" changes i made, or should i revert to the previous state i was at the beginning of the day?
(why do we use "persistence connection"?)
Thank you Igor for the time and patience, i know understand this much better, and learned more than a few things while doing so.
Thanks,
Hagai
Original Message:
Sent: 10-26-2020 07:57 AM
From: Igor Perevozchikov
Subject: Boot WinPE (via PXE) fails on selective machines.
"Altiris Application Metering Agent", "Deployment Solution Plug-in" and "Software Management Solution Agent" these agents aren't built-in plugins in Symantec Management Agent and they related to separate Solutions and they have own Install/Upgrade rollout policies.
To install/upgrade these plug-ins, use these rollout policies:
SMP Console -> Actions -> Agents/Plugins -> Roll out Agents/Plugins
------------------------------
Software QA Engineer
Broadcom Inc.
Original Message:
Sent: 10-26-2020 07:39 AM
From: Hagai Nachmani
Subject: Boot WinPE (via PXE) fails on selective machines.
Hi Igor! :)
Ok I see the "Push Policy" option now , that's great :) thanks!.
Sadly, after doing all instructed above, the laptops are still getting the most updated agent version (8.5.5723), but still not all the plugins (missing "Altiris Application Metering Agent", "Deployment Solution Plug-in" and "Software Management Solution Agent").
I have validated that all "persistent connection" are enabled and active (so does the configuration on the default NS server.
only thought (and I noticed also), that the agent version didn't get pushed to the TS servers across the sites, so maybe when the TS servers get the updated agent version, then the machines on that site will also get the changed made?
I have checked the "site server" settings, and they seem OK, (even "pushed policy" on them). is there a way to force agent refreshment?
Original Message:
Sent: 10-26-2020 07:12 AM
From: Igor Perevozchikov
Subject: Boot WinPE (via PXE) fails on selective machines.
"Push policy" action on policies will be available only if persistent connection functionality is enabled in Notification Server (It's your choice whether you need this functionality enabled or not)
"Push Policy" action will deliver policy only on persistent connected client computers.
To control network bandwidth, you can use in Targeted Agent Settings policies
------------------------------
Software QA Engineer
Broadcom Inc.
Original Message:
Sent: 10-26-2020 06:52 AM
From: Hagai Nachmani
Subject: Boot WinPE (via PXE) fails on selective machines.
Thanks Igor!
For some reason we recall that the persistent connection option should be disabled due to massive bandwidth consumption.
is there a way to control the data being sent over the network somehow? (If using "tickle protocols", isn't it enough instead of the persistent connection?)
In any case, I will follow instructions to the letter and try to achieve this accordingly.
will these instructions also add the "Push Policy" option on the right mouse click you mentioned above that we see is missing from our menu content?:
Original Message:
Sent: 10-26-2020 06:28 AM
From: Igor Perevozchikov
Subject: Boot WinPE (via PXE) fails on selective machines.
HN: My "AeX SWD Execution" event view looks different that yours, maybe that is the issue? :
IP: To see "AeX SWD Execution" events of required client computer, you can mouse right click on this computer (for example on computer in your opened "Agent Connection Status" report, -> then click on "Resource Manager" in context menu of right clicked computer -> in opened "Resource Manager" page, click "View" -> "Events"
HN: and lastly from some reason, on the Cloned Policy, I don't have the "Push Policy" option on the "right click option" , how can I enable it?
IP: You don't see "Push Policy" option, because you don't have enabled "Persistent Connection" in your Notification Server.
To enable this functionality, you need to:
1. SMP Console -> Settings -> Notification Server -> Notification Server Settings -> enable "Persistent Connection" and save changes
2. SMP Console -> Settings -> All Settings -> find there default NS communication profile -> open it and enable persistent connection -> save changes
3. SMP Console -> Settings -> Notification Server -> Site Server Settings -> open Global Site Server settings and enable Persistent connection option -> save changes
Now you need to refresh policy on NS and client computers.
Maybe you can open RDC to affected client PC and check what happens there with SMA Upgrade rollout policy? Open SMA UI there and check Software Delivery tab to see current state of rollout policies?
------------------------------
Software QA Engineer
Broadcom Inc.
Original Message:
Sent: 10-26-2020 05:42 AM
From: Hagai Nachmani
Subject: Boot WinPE (via PXE) fails on selective machines.
Hi Igor, thank you for helping with this. I have checked all 3 suggestions you gave:
Clients indeed received SMA latest rollout policy:
I am using ITMS 8.5 RU4 (with October 22nd Cumulative fix updates)
Machines still show missing Plugins, any additional suggestions?
Thanks,
Hagai
Original Message:
Sent: 10-26-2020 05:10 AM
From: Igor Perevozchikov
Subject: Boot WinPE (via PXE) fails on selective machines.
Maybe client computer is offline and didn't receive SMA Upgrade rollout policy
You can check date/time when client PC had last communication with NS, using default report "Agent Connection Status"
Maybe NSE queue is full and already upgraded SMA on client pc basic inventory isn't yet processed by NS so data is not up to date (you can check NS log to see whether there are messages like Queue is full, etc) You can create "Send Basic Inventory" & "Update Client Configuration" tasks and schedule them to affected not yet upgraded clients.
Maybe client PC can't download SMA upgrade package on SMA upgrade failed, this can be checked from "Resource Manager" page of this client pc, mouse right click on affected computer from SMP Console -> resource manager. Click View -> Events -> check "AeX SWD Execution" for Symantec Management Agent package (If there is no records about Symantec Management Agent package execution, then it means that this client even didn't download it)
To force re-attempt for SMA Upgrade, you can clone existing SMA Upgrade rollout policy and via right click menu on cloned policy "Push Policy" so clients with established persistent connection with NS, will immediately receive this upgrade policy.
------------------------------
Software QA Engineer
Broadcom Inc.
Original Message:
Sent: 10-26-2020 04:33 AM
From: Hagai Nachmani
Subject: Boot WinPE (via PXE) fails on selective machines.
hi Igor!
You are correct, it seems these devices have only partial list of the Agent/Plugins :
Should be:
Original Message:
Sent: 10-26-2020 02:08 AM
From: Igor Perevozchikov
Subject: Boot WinPE (via PXE) fails on selective machines.
Hi Hagai!
please check this KB where same error code described
https://knowledge.broadcom.com/external/article?legacyId=TECH224087
Seems like client computer doesn't have Deployment Solution plug-in installed.
Example of Boot to failed task on client PC where DS agent isn't installed
Thanks,
IP.
------------------------------
Software QA Engineer
Broadcom Inc.
Original Message:
Sent: 10-25-2020 11:12 AM
From: Hagai Nachmani
Subject: Boot WinPE (via PXE) fails on selective machines.
Hi Experts,
I know this lacks some data, but we are trying to audit the task of a Boot WinPE onto a selective laptops. (5 devices)
- In order to redeploy an OS we run 3 tasks:
- 1st is to install the WinPE (always works)
- 2nd tasks is to run the Boot into WinPE (reboots the machine and enter the WinPE) - works on 2 out of the 5 devices (never works on VM machines for some reason) - but when fails, it gives this error code: "-2147221005" (all devices are the same laptop, all on the same segment, and with the same OS on them).
- 3rd and final task is to deploy the desired OS we want , using a *.bat script from inside the WinPE (always works 100% OK).
can you please help us know why does task number 2 gives such error code, and how to resolve it? the same task that fails works on some tests that we make, so we think the configuration are correct, but maybe there is something we neglected to check / configure? :
Thanks,
Hagai