So now I want to show you some of the options that are available and some of the best practices around
deploying software packages using group policy.
When you deploy a package, you'll see this advanced page that comes up.
And it gives you the ability to set a bunch of options on the package deployment.
So for example, you can set the deployment type to either published or assigned.
And if this were a per computer deployment, you wouldn't see the published option or it would be grayed
out.
So you'd only have the ability to assign.
And then you've got a bunch of deployment options like the install on first use option, which allows
you to install an application by the file extension.
And what that means is, as in the example I gave previously, if you get a PDF file as an attachment
and you don't have a PDF reader installed the first time you click on that PDF, if the PDF reader has
been published to the user, it will automatically trigger the install.
The install will occur.
Package.
The reader will be installed and it will open with that document that the user clicked on.
So this is kind of the install on first use model.
The other option below it uninstall is its application when it falls out of the scope of management
means that the app gets removed when the GPO is no longer in scope.
So for example, if the GPL that delivered the app, the Adobe Reader package gets deleted or unlinked,
or the user moves from one you where the GPO exists or is linked to another where it's not.
Then the package will be installed when the user logs on the next time, and then you have the option
for published apps to not have them appear in the add remove programs, control panel applet.
That is the default.
So when you publish an application, it will automatically appear in add removed programs, but you
can tell it.
I don't want to do that.
I'd rather, you know, basically not have it appear so the user doesn't have a choice of when they
install, it gets installed, for example, when they click on that PDF file.
And then you can also choose the UI that appears when the application or the package is installing.
So in most cases, you're going to want to choose basic unless you want the user to get a lot of feedback
about what's going on in the installation.
So basic is as close to silent as you can get in an installation of group using group policy for a package.
Now, some other package options.
There's a bunch of tabs within this dialog you can set upgrade relationships.
And I talked about this earlier.
So if I had packages that upgraded my current package, I could add them here.
Again, I can use I can select the categories for the application that I'm publishing.
So as in the example I gave previously.
If I have a utilities category, I can assign it to this Adobe Reader package.
And I can set modifications.
This is where you can use MSI transforms to modify the default behavior of the install package.
So I can add and dot msg t as in tom file to this package and that transform will modify the package
and the packages behavior as it's installed by the computer or user.
And then finally I can actually set the security on the package.
And this is kind of a I'd call a poor man's security group filtering for individual packages.
It lets you if you remove, for example, the re permission from a particular group for this package,
then even though they might process the GPL that contains this package, they will not be able to install
the application because they don't have read permissions to it.
So you could have, for example, a GPO with five packages deployed to the Marketing Users Group.
But if there's a particular user in the marketing user's group that does not have red access, perhaps
you deny read to the Adobe Reader package.
They would not actually install that package.
So there's some granularity you get with the security tab in terms of who actually runs those package
installations.
So let's shift gears and talk a little bit about best practices.
The one best practice that I always, always have always recommend is to store your MSA installer packages
on distributed file system or DFS shares.
And the reason that you need to do this is if you stick it on a single server and a server share.
If that server needs to go away, you retire the hardware or the server crashes and you're unable to
recover it.
That that link between the server USC path, the share path and the software that's been deployed to
all those computers for users is broken.
That link is broken and essentially the package is orphaned.
You'd not be able to it won't be install from those systems or those users, but you wouldn't be able
to upgrade that package anymore.
You wouldn't be able to patch that package.
So I highly recommend for a number of reasons, using DFS for storing your installer packages.
And this is just a kind of a screenshot of the DFS management tool and how you can create a namespace.
In this case, I called it packages.
And underneath it there's a link to the installer share used for computer assignment unless you want
the application to follow the user to every machine.
So you know, there's probably very few situations where you want to use per user deployment of applications
because it does mean that every time the user logs onto a machine where that application isn't installed,
they're going to get that application installed.
And if it's an application that has licensing restrictions, you're going to leave machines littered
with installed applications that may exceed your license count.
So I typically recommend all you can do per user.
I typically recommend to stick with the per user.
I'm sorry.
Per computer assignment and then use the administrative install option of the MSI package.
And this allows the package to be patched.
And I'll talk about this in my demo.
But essentially what this means is when you instead of just copying the MSI file to your DFS share,
you're going to actually do an administrative install of the package and that does a special kind of
deployment of the package to that share that allows it to be patched down the line.
Don't allow users to install CI deploy packages.
The reason for this is that essentially orphans that machine, you can't get the package back to the
machine using group policy if the user has sort of broken the relationship between group policy and
the machine.
And this is kind of another brittleness of the CI feature that you definitely don't want the user being
the one that installs a group policy deployed package and then finally transforms can only be applied
at the time that you deploy the package.
So if, for example, you deploy an MSI and then you decide afterwards you want to modify it with a
transform, you can't do it.
You can't add that transform after the package has been deployed.
You have to recreate the package, redeploy it to all your clients with the transform assigned to it.
So let's go now and look at walking through kind of a sample deployment using group policy software
installation to see how this works and how you can leverage it in your environment.