09-16-2020 09:17 AM
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?
