I am working on testing improvements to our rule sets by breaking the rules into app groups as opposed to just allow all.
Pretty much everything is working fine except for OSD deployment via SCCM. In particular the O365 click to run installer. The deployment process runs fine up to the point of installing office where it hangs for a very long time. The image completes but the app has not installed. I see a lot of aged-out connections from the PC to the SCCM server which is located on another site. When I add a test wide open rule of allow all/ any/ any, etc it works fine. App-id is working in that it logs it as ms-sms and is hitting the right server. I have tried changing the policy to service any and also removing the security profiles but it still fails. Wireshark on the PA and the SCCM box show me 3 way handshakes, a few initial packets over HTTP and then an rst from the PC as SCCM has not responded. I learned today that with SCCM and CTR installers that there is potentially an initial connection, a download of an XML config file and then a connection to the web to download the latest version. Which would explain the behaviour that I am seeing. This would mean secondary sessions and potentially having to leave an any/any/any rule in place which defeats the purpose of the rule sets.
Has anyone else had to deal with this and found a solution?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!