I have multiple P25 zero clients in my environment that I am needing to push the latest image to. They are all showing up in Device Manager in WDM 5.0. If I select one (running image 42r4_2@15160), right-click, select Package Distribution Wizard, select Images, select the new image (47r4_7@16934), click Next, select the distribution to occur Now, click Next, then Finish; I can see the scheduled package in Update Manager. It immediately shows In-Progress, the almost as quickly errors out. Unfortunately, no error details are listed in Update Manager. The only change I can see on the P25 is that the peer device connection was changed from my View Connection Server to the Connection Management Interface with the IP address of my WDM server. Why won't this go through? Is there some configuration I am missing??
When you installed WDM there in Gotham did you opt to install/enable the FTP protocol for your SWREP? The P25 devices are limited to FTP for file transfers. They would be unable to download your new Firmware if the SWREP is only configured to support HTTPS.
Ok this is still not working. Can you please walk me through how to check and make sure all applicable settings are set correctly for zero client image pushes to function as expected?
Batsy- did you enable FTP in IIS and in WDM? Under Cfg Mgr > SWREP > MASTER > Properties> Enable the FTP option and populate the requisite fields - on completion it'll attempt to validate the connection. If successful then that's a good sign FTP should work. You'll also want to enable the global FTP preference (Cfg Mgr > Preferences) so that WDM can use FTP when deploying updates.
If that fails doublecheck the IIS settings for FTP site. The Admin/Install guides outline the manual cfg process but the short version is point default FTP site to c:\inetpub\ftproot, enable user isolation, grant read/write/execute rights to your Rapport user (created during install).
Once the SWREP test connection passes with FTP then retest your new FW package.
If it continued to fail - I'd check the IIS logs for FTP to see if that device was attempting to connect to get the FW. You should also be able to login to the device using the Admin web console to review the local logs for possible errors.
Ok, I checked all the settings and everything appears to be set correctly. The SWREP has FTP, HTTPS, and CIFS all enabled. When I check this and hit ok, everything tests and passes. I tried the deployment again, and it still fails. I didn't mention this before, but when I try to install the package the connection type on the zero client switches from View Connection Server to Connection Management Interface and all I see on the zero client screen is a green Connect button. Also, while searching the log file on the P25 management console, I see the following:
4d,00:47:15> LVL:2 RC: 0 MGMT_DISC_DNS :(DNS SRV: Config Tool) Discovery complete: 192.168.1.109 4d,00:47:33> LVL:2 RC: 0 MGMT_FW_PROV :Download start 4d,00:47:33> LVL:2 RC: 0 MGMT_FW_PROV :New firmware build suffix is: 4d,00:47:33> LVL:2 RC: 0 MGMT_FW_PROV :New firmware tag is: r4_7@16934 4d,00:47:59> LVL:2 RC: 0 MGMT_UI :DISCONNECTED: transition 3 into DISCONNECTED 4d,00:47:59> LVL:3 RC: 0 MGMT_PWR :(ui_cback): event: 2 - ignored 4d,00:47:59> LVL:3 RC: 0 MGMT_SYS :(ui_cback): event: 2 4d,00:47:59> LVL:3 RC: 0 MGMT_SYS :(ui_cback): queuing EVENT_UI_CONNECT 4d,00:47:59> LVL:3 RC: 0 MGMT_SYS :CONNECT_PROMPT.PENDING_UI_OR_CMS_PROMPT: transition 40 into CONNECT_PROMPT.SESSION_REQUEST 4d,00:47:59> LVL:2 RC: 0 MGMT_UI :tera_mgmt_ui_set_session_state: STANDALONE 4d,00:47:59> LVL:2 RC: 0 MGMT_UI :tera_mgmt_ui_osd_display_main_dialog: CANCEL 4d,00:47:59> LVL:3 RC: 0 MGMT_SYS :Num pending CMS transmits require confirmation: 1 4d,00:47:59> LVL:2 RC: 0 MGMT_UI :DISCONNECTED: transition 21 into DISCONNECTED (MSG_SESSION_STATE_CHANGED: STANDALONE) 4d,00:47:59> LVL:3 RC: 0 MGMT_SYS :(cmi_cms_transmit_status_cback): transmit_success: 1 4d,00:47:59> LVL:3 RC: 0 MGMT_SYS :(cmi_cms_transmit_status_cback): Num pending CMS transmits require confirmation: 0 4d,00:47:59> LVL:3 RC: 0 MGMT_SYS :(cmi_cms_transmit_status_cback): queuing EVENT_CMI_TRANSMIT_SUCCESS 4d,00:47:59> LVL:3 RC: 0 MGMT_SYS :CONNECT_PROMPT.SESSION_REQUEST: transition 97 into CONNECT_PROMPT.WAITING_FOR_SESSION_START 4d,00:48:28> LVL:2 RC: 0 PROMMER :Download error - file 4d,00:48:28> LVL:1 RC:-505 MGMT_FW_PROV :Fail to write 4d,00:48:28> LVL:2 RC: 0 MGMT_FW_PROV :Download incomplete - file unavailable
Can you make any sense of this?
Looks like fileserver issue from the logs. At the top you can see its given the correct name for FW (based on your first post) so the mgmt. communication is correct. That just leaves us with transfer issues since it seems that file is inaccessible - as noted in the last line. Were you able to grab the segment of IIS logs pertaining to this? Should be c:\inetpub\logs\ftpsvc with a new file each day. Hopefully you aren't doing a lot of FTP traffic so it'll be easy to spot your client IP near the bottom of that file (latest entries).
Did you rename the package or folder structure by change?
I believe its expecting something like ../ftproot/rapport/<firmware>/<firmware>/<firmware>.all
Are you using and IP or FQDN for the SWREP location that isn't resolvable by the P25? It might resolve locally and pass the test connection on the server but no from the device. Example 127.0.0.1 as an IP would pass locally (loopback is unlikely to be you issue but demonstrates how it could work)
I attached the most recent log file from the c:\inetpub\logs\logfiles\ftpsvc2 directory. As far as I know, I did not adjust any ftp settings. I am using the IP address of the WDM server for SWREP (192.168.1.109).
Also, I see the ALL file in the following directory:
Don't know if this makes a difference, but I noticed this is different from what you posted (only one "firmware" folder instead of two).
Easy to loose track of those <firmware> duplicates when multitasking - sry
Logs should be a great help here as this entry shows access denied on the file in question
RETR /rapport/47r4_7@email@example.com 550
Now normally WDM installs a windows username called "Rapport" but your logs show you changed that to "Admin". While I'm going to recommend you NOT assign the Admin account for SWREP usage (especially with FTP as clear txt transfer exposes the pwd) I suspect your issue is with IIS FTP user isolation or outright lack of windows explorer permissions on that directory tree ./inetpub/ftproot/Rapport/ by using a custom username
From commandline on the server try to download the same file using the same "Admin" account defined in WDM:
Start > run > cmd
That's what the device is attempting to do. You should get the same 550 error.
The way I'd resolve this is create a windows user "Rapport" and to replace the "Admin" account you've currently defined. Then update windows permissions on c:\inetpub\ftproot\rapport to specifically grant the Rapport account FULL ACCESS to the Rapport directory tree. That would resolve both the security concern using that Admin account and should address the FTP error without you touching IIS.
Run that same cmd test above using the Rapport account this time. If it works then redeploy the firmware.