Cannot push new ThreadX image to P25 zero client using WDM 5.0

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.

-k

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. 

-k

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/ / / .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)

-k

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?

Easy to loose track of those 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@16934//47r4_7@16934.all 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

ftp localhost

admin

get /rapport/47r4_7@16934/47r4_7@16934.all

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.

-k

Also, I see the ALL file in the following directory:

c:\inetpub\ftproot\rapport\ \ .all

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).

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).

I ran the ftp get command, and it worked just fine.  Does this mean that the problem is not with the admin user?

User (*wdm server*:(none)): admin
331 Password required for admin.
Password:
230-User logged in.
 Win32 error:   The operation completed successfully.
 Error details: File system returned an error.
230 End
ftp> get /rapport/47r4_7@16934/47r4_7@16934.all
200 EPRT command successful.
125 Data connection already open; Transfer starting.
226 Transfer complete.
ftp: 11581232 bytes received in 0.22Seconds 52882.34Kbytes/sec.

What now?

Any other ideas karaziel?

Did you see my suggestion on changing the user from admin to Rapport? 

According to your logs your test should have resulted in the same access denied error - both are just FTP connections to IIS FTP server (WDM is really out of the picture at that stage).  I still think it could be related to user isolation.  Have you called into the Wyse Helpdesk to see if they can remotely view your server to validate the configuration?  Since the logs showed a 550 access denied IIS/explorer permissions should be the focus for review.

-k