Web Filtering and IOS update

An exception for File Extensions and MIME types should handle your problem, and this product works.   This leaves these possibilities:

1. You tested too soon after making the change.   There is a reset process after a change is made to an exception entry.  This is usually brief, a few minutes.  Toggling the exception off and back on will expedite the reset.    Not usually an issue, but worth mentioning.
2. You have the wrong URL.   Lots of update services will initialize using an FQDN, then transition to an IP address for the heavy lifting.   That is why Bob pressed you to show the actual block record from the log.
3. Your regular expression is wrong.   I do not see anything obvious, but I am a little skeptical of the trailing \.? sequence. 

Your regular expressions will almost certainly allow stuff that you do not want, like server1.apple.com.badguys.com.   I am adequately competent on regular expressions, but I find that it is very difficult to write one that allows everything that I want without allowing something I do not want.   Fortunately, another UTM feature eliminates the need for regular expressions in most situations.

• Create a Website entry for your intended FQDN (something.apple.com), or better yet for the organization with subdomains included (apple.com).   
• Assign the website to a Tag, which you create with a meaningful name, such as "Downloads Allowed".   
• Then configure an Exception object and link it to the Tag.

With this approach, you only need regular expressions when you are matching the path or query string of a URL.  In my experience, this is rare.   

Note that matching on path or query string will only be possible for HTTP, HTTPS-with-Inspection, and FTP-with-Standard-Mode-Web .   When using HTTPS-without-Inspection, the path and query string are in the encrypted portion of the record. 

An exception for File Extensions and MIME types should handle your problem, and this product works.   This leaves these possibilities:

1. You tested too soon after making the change.   There is a reset process after a change is made to an exception entry.  This is usually brief, a few minutes.  Toggling the exception off and back on will expedite the reset.    Not usually an issue, but worth mentioning.
2. You have the wrong URL.   Lots of update services will initialize using an FQDN, then transition to an IP address for the heavy lifting.   That is why Bob pressed you to show the actual block record from the log.
3. Your regular expression is wrong.   I do not see anything obvious, but I am a little skeptical of the trailing \.? sequence. 

Your regular expressions will almost certainly allow stuff that you do not want, like server1.apple.com.badguys.com.   I am adequately competent on regular expressions, but I find that it is very difficult to write one that allows everything that I want without allowing something I do not want.   Fortunately, another UTM feature eliminates the need for regular expressions in most situations.

• Create a Website entry for your intended FQDN (something.apple.com), or better yet for the organization with subdomains included (apple.com).   
• Assign the website to a Tag, which you create with a meaningful name, such as "Downloads Allowed".   
• Then configure an Exception object and link it to the Tag.

With this approach, you only need regular expressions when you are matching the path or query string of a URL.  In my experience, this is rare.   

Note that matching on path or query string will only be possible for HTTP, HTTPS-with-Inspection, and FTP-with-Standard-Mode-Web .   When using HTTPS-without-Inspection, the path and query string are in the encrypted portion of the record.