blhess Absent Member.
Absent Member.
1226 views

update 3 Deployment failures

new install. ZCM 17.3.0 Deployment of the ZENworks Agent, we are having issues with Deployment to our windows 7, Windows 8.1 and Windows 10 clients. The odd part of the problem if I have a list of 10 workstations. 1 to 2 of the client workstations will successfully deploy. The others fail with. “Error: An unexpected fatal exception occurred” If restart the deployment task with no changes, 1 or 2 more will be successful while the rest fail. I can repeat this cycle until all are successful.
So I realize I need to dig more to find more information, where and what logs names would be ones to start with? I do not find anything odd in workstations windows logs, I do sometimes see the successful user authentication, the user setup in the Credentials of the deployment task.

Please let me know if left off some needed information

Thank you,

Brian Hess
Director of Information Technology
SC Telco Federal Credit Union
Ph (864) 370 5980
Labels (1)
0 Likes
5 Replies
Micro Focus Expert
Micro Focus Expert

Re: update 3 Deployment failures

Are you sure all of the devices are up and running at the time? (Device may even be up, but NIC asleep for example depending on the lower power state...)

Basically ZCM is doing the functional of a PSEXEC command that copies the installer and then kicks it off.
Sounds as if ZCM cannot connect at that time.

I presume the devices are are in a Windows Domain? (Non-Domain Joined Devices generally do not allow for remote software installs by default.)

If some type of Device Start Up script via the Domain GPO may be simpler....
(Script Verifies if Device is in Device Group that gets the ZCM Agent, Verifies the agent is not installed, and then installs if not....reboot suppressed to avoid bothering users...)

Eliminates the need to keep scanning to find PC to deploy...in hopes they are powered on and on the network at that time to get the list of devices to deploy.
Then repeating the process in the hopes they are on when you deploy....
0 Likes
blhess Absent Member.
Absent Member.

Re: update 3 Deployment failures

All the PCs on same domain
same subnet
all the pcs are powered on either at login screen or some one is using the PC, I check right before starting, some times I have physically checked.
I wanted to work this issue, since I am worried this problem my be hint of issues with other features down the road.

CRAIGDWILSON;2490074 wrote:
Are you sure all of the devices are up and running at the time? (Device may even be up, but NIC asleep for example depending on the lower power state...)

Basically ZCM is doing the functional of a PSEXEC command that copies the installer and then kicks it off.
Sounds as if ZCM cannot connect at that time.

I presume the devices are are in a Windows Domain? (Non-Domain Joined Devices generally do not allow for remote software installs by default.)

If some type of Device Start Up script via the Domain GPO may be simpler....
(Script Verifies if Device is in Device Group that gets the ZCM Agent, Verifies the agent is not installed, and then installs if not....reboot suppressed to avoid bothering users...)

Eliminates the need to keep scanning to find PC to deploy...in hopes they are powered on and on the network at that time to get the list of devices to deploy.
Then repeating the process in the hopes they are on when you deploy....
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: update 3 Deployment failures

This feature really has nothing to do with ZENworks itself.
ZENworks is not on the devices and cannot be used.
At this point in time, it is all pure native Windows Networking and other Native Windows Processes.
Think "PSEXEC"....which just calls into running Windows processes.
That is all we are doing....just using the same APIs that PSEXEC uses.

Possibly the NICs went into a Sleep State and could not connect.
(See - https://blogs.technet.microsoft.com/exchange/2013/10/22/do-you-have-a-sleepy-nic/ Quite Often Enabled on End User Devices.)

Perhaps another install was in place locking the installer service at that time.
Perhaps the installer service was locked pending a reboot.


Since it eventually works, it is not an issue of Firewalls, Server Service Stopped, Admin Shares Off, Forced Guest, or a litany of other pre-requisites to remotely install software on a PC.
By Default, a Non-Domain Joined PC will not permit remote software installs.
Domain Joined PCs have different Default Security Settings that do permit remote software installs, but often these are disabled or highly restricted by Domain Policies.
However, you should be aware of all of the requirements to remotely install software using Native Windows Tools to ensure that this is enabled on all of your devices as you spread outside of your lab.

The Advantage of using a Domain Startup Script is....
#1 - No need to worry if Remote Software Installs are Enabled by Windows.
#2 - No need to worry if the PC is Off, Asleep, Off Site, Installing other Software (It will be in a clean boot state...)
#3 - No need to time Discovery and Mobile devices as they will install when they boot up while attached to the network.
#4 - Its faster because each PC can pull independently vs a Remote Server needing to reach out to PCs one at time.

I view Discovery and Deployment more as a secondary method....at least in very large environments.
Good to Find devices missing the agent...maybe it off the domain or never reboots when actually attached, etc....

Trying to troubleshoot why each and every remote push failed....when it eventually works will drive you nuts and often needing to attach to the remote PC to get event viewer logs.
Troubleshooting is better spent on understanding why it never works and what steps need to be taken to resolve that....
Perpetual failures normally comes down to Windows Security Settings blocking remote software installs.
(And No software can bypass that...or it would be the most critical of all possible security defects in Windows....at least as part of the initial install relying upon Built-in Windows Code.)





ZCM code is not involved in the core processes of the remote software install....as that process is just native Windows until we are installed.

I find Discovery useful for finding devices which are missing the agent, but for Large Deployments I leverage the Domain Startup Script.
Much simpler and avoids many of the issues involved in the limitations of pushing software to Windows using the Native Built-in Windows Services...which is all ZCM or any other product can do until the product is installed.

Once the Agent is installed, then ZENworks can take over far more robustly.




blhess;2490075 wrote:
All the PCs on same domain
same subnet
all the pcs are powered on either at login screen or some one is using the PC, I check right before starting, some times I have physically checked.
I wanted to work this issue, since I am worried this problem my be hint of issues with other features down the road.
0 Likes
blhess Absent Member.
Absent Member.

Re: update 3 Deployment failures

Thanks, everyone for the help, I was able to get more success by changing the Deployment Package from the default to "Default Agent (Target Architecture: all install type standalone)" and also put the Deployment to schedule to repeated everyone hr.
98% of the clients was installed over the weekend
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: update 3 Deployment failures

I would recommend bookmarking the TID below.
It is sort of a Master TID on where to set and find logs.
I copied out the part about deployment.....though honestly I would not spend much time on individual devices unless there are widespread failures.

On the ZENWorks Server, the logs for this would be in the "Loader-Messages.log".
The ZENworks Primary Servers have 2 main services....
"ZENserver" which is what agents use to talk TO the server. This is the service agents use to work with the server in real time. (Also ZCC Functionality.)
"ZENLoader" handles background tasks, scheduled events.






https://support.microfocus.com/kb/doc.php?id=3418069

Component Name: Deployment
Enable Debugging (self documenting xml file. Set to FINEST):
Windows server:
%ZENWORKS_HOME%\conf\loader\deployment.xml
Linux server:
/etc/opt/novell/zenworks/loader/deployment.xml
Restart loader service. (novell-zenworks-configure -c Start) will give you the option to restart.
Note: Modify the existing xml file. A file called "copy of discovery.xml" in the same directory will be used if it exists.

Log Location:
Windows server:
%ZENWORKS_HOME%\logs\loader-messages.log
Linux server:
/var/opt/Novell/log/zenworks/loader-messages.log
Windows Workstation:
ZDPASERV.EXE service logfile c:\RemoteSvc.log
%temp%\wincustomaction.log
event log viewer for preagent events
For linux servers that use Windows discovery/deployment proxy, additional logging will be in zmd-messages.log on the proxy device (set to debug).
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.