cancel
Showing results for 
Search instead for 
Did you mean: 

AFARIA without relay server

Former Member
0 Kudos

Hi,

I am currently busy with an Afaria installation that won't be using a relay server.

Devices will be connecting using a Wi-Fi.

May you please advise what the architecture should be like and if AFARIA needs to have a public IP or not.

The issue I am having is that devices failed to register when I try to connect directly to the Afaria server using Wi-Fi.

Both the device and the Afaria server are in the same network.

Please assist

regards,

Monde

Accepted Solutions (0)

Answers (1)

Answers (1)

keith_nunn
Active Participant
0 Kudos

Hi, Magwevana.

When not using the Relay Server it's typical that another reverse proxy server would be in place on the front end or at least a firewall.  Microsoft Forefront Threat Management Gateway (formerly Internet Security and Acceleration) is often used in environments that aren't running a Relay Server.  You may use a public IP on your Afaria Server directly if you wish.  That would be one possible configuration.  However, it's rarely used due to security concerns. 

The key point is that however you have the environment configured, the request from your device needs to reach the Afaria component for which it's intended.  For example, an iOS device enrolling for the first time would need to reach the Enrollment Server component.  Whatever DNS/IP you have configured on your Enrollment Server configuration page in the Afaria Administrator needs to be proper for getting the traffic to the Enrollment Server.

On an internal network where you have a device on internal Wi-Fi and an Afaria Server on the internal LAN, it should be fine to use the internal IP or DNS name of your server.  Traffic intended for the Enrollment Server or Package Server can be checked in the IIS log on the machine where they're installed.  Traffic intended for the Afaria Server itself would need to have a network trace (such as Wireshark) used to verify if it was reaching or not.

Thanks,

Keith Nunn
SAP Active Global Support
SAP Canada

Former Member
0 Kudos

Hi Keith;

We have managed to get the device to enroll via the Self Service Portal but when we use the enrollment code via the afaria client we get "Enrollment failed". On the Afaria server logs we get the following error message :

"IPH6018: Incompatible Enrollment Code. Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36 incompatible with Android"

What could be the most likely cause of this? We are on Afaria 7 SP5 and are connecting from an Android device 4.2.2 and 4.0.4.

Your help is greatly appreciated!

Thanks in advance!

Sizo Ndlovu

keith_nunn
Active Participant
0 Kudos

Hi, Sizo.

Based on the error, it suggests that you're attempting to enroll an Android device using an enrollment code for a different client type.  Check your enrollment policy and ensure that it's an Android enrollment policy.  If it is, please check the long url associated to your short code (can be found by highlighting the short code and clicking the "inspect" icon).  Make sure the end of the long URL is "&ClientType=-10".  If it's a different identifier then it means the URL is intended for a different device type (-11 would be WinPhone, -8 would be iOS).

If the policy is Android and the code ends in -10 then try generating a new enrollment policy and see if that one works.  If so, there is a problem with the data stored related to your enrollment policy and a support case would likely be needed if you wished to determine what the problem is in your database.

Thanks,

Keith

Former Member
0 Kudos

Hi Keith;

Thanks for the response. The enrollment code is for android, it ends with "-10", we have also tried several times generating a new policy with no success. I suspect that you are right with the enrollment policy data store having a problem. Before we go the support direction though, could you kindly have a look at the below device log from the Dalvik Debug Monitor for android, maybe this could help in exactly pin-pointing what the actual issue is:

Thanks and Regards;

Sizo Ndlovu

keith_nunn
Active Participant
0 Kudos

Sizo,

Unfortunately, the logs don't really suggest the cause of the problem.  Looking back at your original error message, it appears that it might be a result of some other step that you're doing.  Afaria determines client type generally based on the User-Agent in the HTTP packet header.  Your User-Agent in that error is "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36".  That suggests a Windows 7 machine attempting to connect to the enrollment URL via a browser (Chrome?).

Is it possible that during your troubleshooting efforts that you tried to open the enrollment URL in a browser on a Windows desktop?

I would recommend that you check the IIS log on your Enrollment Server for a request to the GetEnrollmentSeedData method that corresponds exactly to the time you attempted to enter the code in the Afaria Client on your device and see what the "sc-status" and "sc-substatus" codes are (the HTTP status and sub-status) showing for that request.

If you attempt to enter the enrollment code in the Afaria Client and every time it's generating an error like the one you initially posted then it would be good to get a network trace to capture the packet header and see if your devices are sending an invalid User-Agent for some reason.  If you're not seeing the error but you have a return code other than 200.0 in the IIS log then it might give a better clue on the cause.

Thanks,

Keith Nunn
SAP Active Global Support
SAP Canada

Former Member
0 Kudos

Hi Keith;

You are right, I was testing the URL from chrome on my development machine. The return code showing on the IIS logs is 204, no content! What could this be, any ideas?

Thanks and Regards;

Sizo Ndlovu

keith_nunn
Active Participant
0 Kudos

Hi, Sizo.

The NoContent (204) return code is generally sent when 1) the URL being accessed is considered to be invalid for some reason, 2) the user-agent of the client doesn't match our requirements or 3) when the Enrollment Server is unable to reach the database server.

You mentioned that the SSP enrollment worked.  If this is SP5, can you verify that the enrollment policy linked to your SSP via the Server > Configuration > Component \ Self-Service Portal config page is the same enrollment policy that you're using and that there's only one enrollment code in that policy?

If this is SP4, please check the Web.config in that specific SSP's installation path and verify the enrollment code defined for Android is the same code you're using.

If the code for the SSP matches what you're trying manually and it works through the SSP but not when manually entered, it's likely going to take deeper troubleshooting than a forum post, unfortunately.  So I would request you open a support incident, in that case.

Before opening the incident, after verifying the codes match, try once more to enroll via the SSP just to be sure it still works.  If you are now in a situation where neither works then the circumstances will have changed and it would be good to look at everything again.

Thanks,

Keith Nunn
SAP Active Global Support
SAP Canada

Former Member
0 Kudos

Hi Keith;

We are using Afaria 7 SP5, It seems like the Self Service Portal only passes when we associate the Default Android Enrollment code to the Self Service Portal. When we assiciate it to the manually created tinyurl, it fails. We actually seem to have 3 different codes, the code generated by the tinyurl (manual), the Self Service Portal code and the Default Android Enrollment code. All these codes are different. How do we get them to be the same as you are suggesting, we have reinstalled the enrollment server and ran through different config scenarios with no success, they always seem to be different.

Please see screenshots below:

Default Android Enrollment code:

Self Service Portal Enrollment code and tinyurl enrollment code:

Thanks and Regards;

Sizo Ndlovu

keith_nunn
Active Participant
0 Kudos

Sizo,

The SSP code in your enrollment policy won't match the TinyURL code.  The SSP code is handled by Afaria during redirection of your device from the SSP to the Enrollment Server.  The third party code is deciphered by the third party when the code is entered manually into the Afaria Client app.

Apologies for the confusion.  The default codes and the SSP codes are new to SP5 so they slipped my mind as a possibility.  So, for now, ignore the default codes.  Associate your enrollment policy to your SSP from the Self-Service Portal page.  As long as the policy is associated and the changes saved, it should be good.  Also highlight the third party code and a new option will appear in the medium grey bar above with the label "Inspect".  Click that to view the long URL associated to the short URL.

Save both that URL and the "Enrollment URL" in the "Self-Service Portal Enrollment Info" box in your enrollment policy for reference.  Then attempt to enroll through the SSP.  If it fails, search the IIS log for the matching URL GET and get the return code (the "ID={GUID}" piece is the important part for this).  Then attempt to enroll using the third party code by manually entering it into the Afaria Client when prompted.  If that fails, check the IIS log again for the matching URL and get the return code.

At that point, both enrollment methods should be using the same policy but the URLs will be different so the return code may be different.  If both attempts against GetEnrollmentSeedData return a 204 then it's going to require enabling debug on the Enrollment Server and providing system-specific details that aren't appropriate for a public forum to further troubleshoot the issue.

Otherwise, let me know your results and I'll offer what I can here.

Thanks,

Keith Nunn
SAP Active Global Support
SAP Canada

Former Member
0 Kudos

Hi Keith;

We have since logged a support ticket for this. Thanks for all the help.

Regards;

Sizo Ndlovu