This post has actually been hanging about in my drafts for about a year. I wanted to investigate this a bit more before posting, but now I figure, what the hell!. Before I begin and I will have this in my conclusion, but Managing Windows Firewall exceptions via Group Policy is the best way to go. It’s best to centrally manage these types of settings, in my opinion.
But of course, I didn’t just post this article to state the obvious. I wanted to explore other possibilities for setting Windows Firewall exceptions on a per application basis using the virtual application Deployment Configuration XML File.
I love having the ability to run scripts in the system context, it has completely altered how I look at sequencing using App-V. It’s awesome! With the release of App-V 5.0, we obviously got better application compatibility with the introduction of support for certain extensions like mailto, support for shell extensions and more!
We can now sequence more applications than ever before. But there was always more at play with App-V and what applications can and more importantly Should\will be sequenced. Many customers would choose to not sequence an application if it meant splitting into two separate packages in the past, like for example, drivers. They would not accept this because it meant there was two packages to manage in their deployment. Well now we can bundle the separate package in with the virtual package and execute them together! Well, this method can also be used for setting an application specific firewall policy.
The only reason I even attempted this is because I’m aware over the course of my short career, that several packagers have, in the past set firewall exceptions for their package through the actual package itself, usually through the registry. In Windows Vista and Later, Windows Firewall has been replaced with Advanced Windows Firewall, so previous methods are no longer valid.
You may need to consult HERE for an updated listed of viable commands for setting firewall exceptions. You may also want to consult with the information HERE and HERE for information around scripting for App-V 5.0! I also have an example of scripting for a different purpose in my SQL Management Studio 2012 Sequencing recipe which you can find HERE.
In this articles specific example, I wanted to set a firewall exception for TeamViewer.
To script this using App-V 5.0. You can modify the <MachineScripts> Section in your Deployment Configuration file as follows:
<MachineScripts>
<PublishPackage>
<Path>\\appvmserver\Content\TeamViewer\Scripts\SetFirewall.bat</Path>
<Arguments></Arguments>
<Wait RollbackOnError=”true” Timeout=”30″/>
</PublishPackage>
<UnpublishPackage>
<Path>\\appvmserver\Content\TeamViewer\Scripts\DeleteFirewall.bat</Path>
<Arguments></Arguments>
<Wait RollbackOnError=”false” Timeout=”30″/>
</UnpublishPackage>
</MachineScripts>
Note: In this example, I’m pointing to bat files on a Share. You can of course include these bat files inside your package in the Scripts folder and simply point the Argument to .\Scripts\SetFirewall.bat and Path to cmd.exe. Alternatively, calling the scripts from the content share also works.
You must EnableScripts for App-V 5.0 on your clients, if you have not already.
Note: In the example above, I am using a bat file to set the Firewall exception when the application is published and a bat file to delete the firewall exception.. I have found bat files are the best way to set this as I’m using a variable in the path for the firewall rule. The variable path being used is the directory in which the application is initially added to the system, ensuring the path exists when publishing. Also, this is the path the applications shortcut points to. My bat files contents are as follow:
SetFirewall.bat:
netsh advfirewall firewall add rule name=”Allow TeamViewer” dir=in program=”%LOCALAPPDATA%\Microsoft\AppV\Client\Integration\46F7F9BF-93D8-4806-A915-9B126104B236\Root\TeamViewer.exe” security=notrequired action=allow
DeleteFirewall.bat
netsh advfirewall firewall delete rule name=”Allow TeamViewer” program=”%LOCALAPPDATA%\Microsoft\AppV\Client\Integration\46F7F9BF-93D8-4806-A915-9B126104B236\Root\TeamViewer.exe”
This works great. It’s such a quick and simple command to execute. If multiple firewall exceptions are required, you can just add those also. And by using the bat file, you can execute multiple without issue.
Conclusion
One down side for this, is that in order to add the firewall exception, the script must be run in an elevated context which means the script is executed using the Dynamic Configuration File. I chose to set the Firewall exception on Publishing rather than Add because the command will only run successfully if the path and file exist, which it would not if run on Add. It does exist in Publishing however.
Publishing must be Global, which is a possible issue depending on your environment. If you are concerned with all users of a particular machine getting the application published to them. This is not for you. But nevertheless, it’s effective, it sets the exception and it works. A positive of doing it this way is; that it will only set the firewall as the application is being published, so it’s kind of on demand in a sense. By having it remove on UnPublish, you ensure it’s also cleaned up automatically when the application is being removed. Which obviously you don’t get with GPO. BUT nevertheless my preferred method is still to use GPO for setting Firewall exceptions for my App-V applications.
