Cisco AnyConnect ISE Posture Module prevents Windows 10 roaming profile from syncing to the server

[sulaiman26]

There seems to be an incompatibility issue between windows roaming profiles and Cisco AnyConnect ISE Posture Module  The existence of the module prevents a roaming profile to be copied to the server during user sign off.  Furthermore, there is no error condition or warning logged in the event viewer.  After uninstalling the posture module, windows profile syncs properly to the server after user sign off.  I am able to reproduce this symptom on multiple Windows 10 computers including 1809 and 1903 variants of Windows 10.  If anyone else can reproduce this symptom in their environment, kindly chime in and/or post a possible solution if you have one.

thank you,

-sul.

[dongill]

Hi there,

We also have this problem - we have only encountered it since upgrading our clients to AC v4.7.0352 [VPN, NAM and ISE Posture]. This issue is affecting both our wired and wireless connectivity methods.

We do not see the issue on our previous version of AC v4.5.03040 with the appropriate VPN, NAM and ISE Posture modules when using wired connectivity.

We're busy investigating - no progress so far, but will raise with TAC soon... I'll come back as soon as we make some progress..

[dongill]

out of interest, are you running any AV / endpoint security products on the clients that you are experiencing the issue?

[sulaiman26]

Good morning,

For testing, we installed the Posture module on PC’s w/ McAfee endpoint security and others with the built-in windows Defender AV—they produced the same results of not syncing roaming user profiles to the server.

Hope this helps.

Thanks!

-sul.

[dongill]

Hi sul,

apologies for slow response... 

we too were running mcafee, however we raised the issue with TAC, and after much testing / to and fro-ing it transpires that this issue is due to a bug.

TAC have provided us with a dev AnyCon build and it looks to be fixed! We still have an issue where roaming profiles are not correctly synced when using VPN over non corporate WiFi with NAM (possibly due to NAM, investigation in progress); all other connectivity scenarios now work fine.

Still waiting on public availability of the fixed  version... you may wanna log your issue with TAC if you need to test.

cheers

Don

[sulaiman26]

Hi Don,

thank you so much for sharing.  Could you please share the approximate date when the dev build was issued by TAC and possibly a service request number for reference?  We also asked TAC to resolve this and for the last month or so, all they do is to keep suggesting to work with Microsoft.  Any way, the information will help us a great, great deal.

thank you,

-sul.

[eoladele]

Dongill,

I'm currently working on a similar issue. Are you able to provide the bug ID TAC provided to you as regards this issue?

That'd be very much helpful.

Thanks,

[dongill]

Hi there, 

Sorry for slow reply - The build was given to us in late August; the bug ID I have at this stage is an internal TAC one due to the issue still being investigated. I'm told there are no public details available yet whilst this is with the developers, but it may help your TAC case: CSCvr05314

Unfortunately we are no further on, have asked our Cisco AM to escalate.

Thanks,

Don

[dongill]

Hi - did you have any luck with TAC?

Unfortunately we are still no further on, despite raising with Cisco.
I can only assume this may need to go through the various testing phases before it’s made available...

[eoladele]

Yes....I am a Cisco Engineer. I was able to speak with the Development team on this and I was informed that this issue has been addressed in AnyConnect 4.8MR1. It appears to be on track for release at the end of this month.
I hope this helps.
Regards,

[dongill]

Hi thanks for the update... I can see that Anyconnect v4.8 was released on Oct 29, but I can't find any (obvious) reference to this issue being resolved?

Are you able to confirm if it was indeed resolved, but not included in the release notes?

Thanks

[dongill]

I've had confirmation from TAC regarding our case that this is indeed fixed in this release...

We'll be testing this next week - I'll confirm when done.

[dongill · Accepted solution]

Better late than never - Cisco TAC confirmed the bug was fixed in Any Connect 4.8.01090 - we tested and confirmed the issue was resolved 9/1/2020 - forgot to update the thread, start of 2020 was busy for all of us!!

Hopefully this may help someone running older versions...