RFS: Uploading Content to SSP hangs

Symptom:

After installing and enabling RFS, users are not able to upload documents to the SSP.  The upload hangs and does not complete.  Running the RFS health checks from the RFS server are successful but running the same health checks from either the device accessing the SSP or the SSP server (typically the Device Services Server) fail.  See below for how to run the health checks.  

 

img6.png 

 

Resolution:

This is a networking issue since both the user’s device accessing the SSP and the server hosting SSP need to be able to reach the RFS server.  If you are able to reach the health checks locally from the RFS server but are not able to reach the health checks from the either the user’s device or from the SSP server then networking needs to get updated.  

 

Below are health checks that can be run to show the this is a networking issue.  When running the healthcheck, the version of RFS should be returned (e.g. Version: 2.3.3). If the checks in step 1 are successful but the checks in Steps 2 or 3 fail then this is networking issue. 

 

1.     Verify health Checks Locally on the RFS Server:

 

For Linux RFS versions:  2.0-2.3 (AirWatch 8.1-8.3), On the RFS server verify each of the following:

-       Verify Files Service:                curl -a http://localhost:50001/files/awhealth

-       Verify HAProxy to Files:          curl –ak  https://localhost/files/awhealth

-       Verify Tokens Service:            curl –a http://localhost:50000/tokens/awhealth

-       Verify  HAProxy to Tokens:     curl –ak https://localhost/tokens/awhealth/

Note: this example assumes that the RFS services:  HAPROXY, Files, and Tokens are all on the same server.  If they are on different servers then modify the instructions to meet your use case.

 

For Linux RFS version 2.4 (AirWatch 8.4), on the RFS server:  

-       Verify RFS service: curl –ak https://localhost/awhealth

 

For Windows RFS version 2.3 (AirWatch 8.3) open a browser on the server and verify the following:

-       Verify Files: http: http://localhost:50001/files/awhealth

-       Verify Tokens service: http://localhost:50001/files/awhealth

 

For Windows RFS version 2.4 (AirWatch 8.4) open a browser on the server and verify the following.  (Note cert error is expected because localhost is being used)

-       Verify RFS service:  https://localhost/awlealth

 

2.     Verify the device accessing SSP can reach the RFS server. 

Note: You should not receive a cert error with any of the below checks and  <RFSURL> needs to be replaced with the appropriate url (e.g. https://rfs.company.com).

 

For RFS version 2.0-2.3 (AirWatch 8.0 - 8.3) open a browser on the device and verify the following:

-       Verify Files:  <RFSURL>/files/awhealth 

-       Verify Tokens service: <RFSURL>/tokens/awheatlh

 

For RFS version 2.4 (AirWatch 8.4) open a browser on the device and verify:

-       Verify RFS Service:  <RFSURL>/awhealth

 

3.     Verify the SSP server can reach the RFS server.

Note: This is only applicable for OnPrem Customers. If the the DS server is using an outbound proxy then that needs to be taken into account.   Saas customers can simply run the below health checks from a browser on an outside network.  You should not receive a cert error when accessing the health check.  

 

For RFS version 2.0-2.3 (AirWatch 8.0 - 8.3) open a browser on the SSP server (typically DS server)  and verify the following:

-       Verify Files:  <RFSURL>/files/awhealth 

-       Verify Tokens service: <RFSURL>/tokens/awheatlh

 

For RFS version 2.4 (AirWatch 8.4) open a browser on the device and verify:

-       Verify RFS Service:  <RFSURL>/awhealth

 

 

Have more questions? Submit a request

0 Comments

Article is closed for comments.