- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-08-2013 01:58 AM
We are running Panorama 5.0, but still have some managed devices running 4.1. According to release notes, Panorama 5.0 should be backward compatible with 4.1 devices.
How does Panorama 5.0 treat 4.1 devices when it comes to template configuration? I know that templates are not supported in 4.1, but still it seems to me that some of the configuration I do under templates are pushed to the 4.1 devices when doing a device group commit. As far as I can see, this applies to "server profiles" and "log-settings" under the device tab. When I assign a template to a 4.1 device, and configure a syslog profile(or any other server profile) to that template, that template is actually pushed to the device when I do a device group commit in Panorama.
The reason for asking this, is that I get some kind of verification error when doing a device group commit when some values are configured on both the template and on the device itself. For example log-settings:
I understand the reason for the error, but shouldn't a device group commit ignore the template values when the device is running 4.1?
For this installation I can't simply remove the template from the devices, because log-forwarding in our security policy is actually using some of the server profiles that are defined under the template (happened automatically when we upgraded Panorama to 5.0).
04-10-2013 06:20 AM
No, support did not really give me a good explanation for this. Hard to explain this, but out problem turned out to be mainly with Log settings and Server Profiles, and the fact that we could not delete the templates for the 4.1 devices. When setting a syslog server in a log forwarding profile in 5.0, Panorama can use values configure in the template, but not in the Panorama tab(like in 4.1). We then had to manually add a syslog profile in all templates, even if we had only 4.1 devices. Panorama wouldn't let me commit configuration including the log forwarding profile, unless the syslog profile was configured in device's template. This was an acceptable work around, but we did never get the problem fixed until we upgraded the devices to 5.0.
01-08-2013 09:11 AM
The best option is to open a case with support.
The unsupported template options in 4.1 should be dropped at commit time. I.e. Device > Log Settings > Config. These were not supported to be pushed prior to 5.0 so they should be dropped on the device prior to an attempt to commit the combo Device and Panorama config.
01-08-2013 11:34 PM
Thanks for your reply.
I'll open a case with support, and have them take a look.
04-09-2013 02:48 PM
We ran into this same issue a few months back, but at the time support wasn't able to provide a solution and we reverted back 4.1.9. I'm curious, did they provide you with a solution that you could update here?
I've personally found through lab testing that the issue seems to lie with the automatically generated device templates created when panorama is upgraded to 5.0. deleting the device templates for our 4.1.x devices allowed the commits to succeed without issue.
04-10-2013 06:20 AM
No, support did not really give me a good explanation for this. Hard to explain this, but out problem turned out to be mainly with Log settings and Server Profiles, and the fact that we could not delete the templates for the 4.1 devices. When setting a syslog server in a log forwarding profile in 5.0, Panorama can use values configure in the template, but not in the Panorama tab(like in 4.1). We then had to manually add a syslog profile in all templates, even if we had only 4.1 devices. Panorama wouldn't let me commit configuration including the log forwarding profile, unless the syslog profile was configured in device's template. This was an acceptable work around, but we did never get the problem fixed until we upgraded the devices to 5.0.
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!