Wi-Fi profile push stuck

[Ramkumara11]

WE are trying to push the Wi-Fi profile (Has the credentials payload obviously) via M.S.FT CA to our iOS.

Since 13 hours the profile is simply stuck: What we can do to resolve this and speed up push?

WE are over-sized in our architecture, so that isn't a problem!

Steps already done:

1. Rebooted console 2 times.

2 Cleared the queries on the DB using command

select * from deviceCommandQueue.DeviceQueue where (CommandID=XXXXXXXXX and DeviceProfileVersionID = YYYYYYYYYYY)

[chengtmskcc]

Are you experiencing the same issue with pushing other profiles? Or just this WiFi profile?

[Ramkumara11]

chengtmskcc​ Its basically any profile with "certificate payload

Its quite frustrating really, what we can do to quicken this?         

[chengtmskcc]

Any issue with communication between your UEM console and your CA?

[Ramkumara11]

No not at all

Profile push is happening, its so damn slow.

Any way to quicken this?    

[chengtmskcc]

I would try maybe restarting the ACC server(s) first.

[Ramkumara11]

Thanks mate,

Would u suggest we restart the A.C.C or the console?   

We rebooted the console, but that did not seem to help much. Do assist.         

[chengtmskcc]

How is your environment architected? Do you have N+1 server for every AirWatch component?

If you only have one server for each component, then restarting the AirWatch service might be sufficient. Start with ACC first before the console server.

If you have N+1 server behind a load balancer, then you may want to limit traffic to a single node and see if it helps resolve the issue.

[Ramkumara11]

1. WE are over-sized mate.
2. 7 D.S servers, 2 Console, 3 A.C.C and 1 DB.
3. All on-premise on 19.07
4. Any tips to speed up the process?

[rterakedis]

Ramkumara11​ - I have seen in the past where profiles that use ADCS-generated certificates can sometimes take a long time to deploy.   The reason for this usually ends up being something related to the following:

1. The number of devices which need the profile is large.... leading to...
2. A large number of certificate requests being made to the CA which may be undersized.

Remember, each time you request a new certificate from the CA it has to do the math to generate the unique key for the certificate (at whatever bit length you specify).   A lot of times I’ve seen where the Root CA is a physical machine locked away in a closet, but the intermediate CA(s) run on  VMs which are not sized for mass certificate generation.   I would say you might want to open a ticket with Support and they can help you look at the DB to determine if these processes are waiting on the CA to return the certificate to get embedded in the profile.

As a quick test, one option would be to watch the CA specified in your credentials payload to see if new certificates are being generated and if so, how many are being generated over a certain timeframe.