Savij

Setting the Publish Point

The next thing we need to do it setup a publish point. We can do this with a file share, an IIS virtual on a web server, an FTP, etc. For the purposes of this document we are going to use a file share. If you would like to use IIS because you want to hook the http headers and do silly things like that, you can just change the UNC path that we will use with an http path.

It is important to remember that our publish point is private so that we can make changes to the deployment before issuing it for public consumption. With that in mind, lets create a couple of directories. Using the famous Noble Nomenclature (sometimes called Nobleclature, or lazyclature), I will create two directories as follows:
c:\1Deploy_DEV
c:\1Deploy_PROD
The 1 makes these stay at the top of the folder listing and also makes you think of yourself as number 1 when you type it .

The next step is to create shares for these. This is where the UNC path stuff comes into play. I will right click and share these folders as file://machinename/DeployDEV and file://machinename/DeployPROD.

Now that we have our publish points created, it’s time to tell Visual Studio and Click Once about the drop locations. We will be working on creating a Click Once deploy for production first.

Right click the Properties folder in your shell project and select Open. Then select the Publish tab. 

 Type in your UNC path into the Publishing Location and then select ‘The application is available offline as well (launchable from the Start menu)’. I am selecting this instead of online only, because my application will allow people to use it in an offline mode. I also don’t like to tie all of my users to a network resource. Lets say I used a Publish location of http://myintranet/myapplication/hello.application. If the web server that hosted this resource were to go down, nobody would be able to launch my application. Remember that my network is up and running, it’s just that one box that went down (not that IIS EVER has trouble). For this reason, I use unc paths. I can have my installation files hosted on a box that is mission critical. If that box goes down, my application is probably un-useable anyway. In addition to this, I like to allow for launching even if the network is down. I can collect data in an offline mode, and then batch import it when the network comes back. This makes me happy, and this is what I shall do .

Your version will start out at 1.0.0.0 and will increment automatically (as long as the checkbox is checked) with each publish. Notice that mine shows I have published 4 times already and am ready for publish 1.0.0.5.

Checking and Fixing Application Files
Next we move on to the Application Files Button. Clicking it will reveal a couple of problems for CAB.

The First problem is the ProfileCatalog.xml file. This file gets incorrectly marked as a data file. As such it won’t be available to CAB after it deploys. Make sure you change the publish status to ‘Include’ for this file. I changed all of them to include, but I really am not sure what the effect of this is as opposed to Include (Auto). I just don’t trust most things that claim to be automatic. Look at Martin Gramatica, he used to be called Mr. Automatica and look what happened to him.

The next thing to notice is that in the list of applications, you don’t see ANY of your CAB modules you worked so hard on. This is because Click Once only see’s the output files in the project and the project references. This will not work for us. We will go ahead and leave it this way for now. We will even publish it this way, but then we will add the missing files (more on that later).

Changing Our Options
After clicking OK we need to click on the Options Button. In this dialog we need to change the Publisher name and Product name. The product name is the name that will be displayed on the start menu after this application deploys. It does not however tell click once that this is a different installation. In other words, just changing the Product name here and re-deploying will not result in two start menu icons. The start menu WILL use this name, but ClickOnce will still treat these builds as if they are the same. Deploying the second time will overwrite the existing start menu item. We will cover how to avoid this later. I just wanted to point out that this is the name that goes on the start menu and nothing more.

I also unchecked the Open deployment web page after publish. I don’t like being spammed by browser windows from Visual Studio.

A Word on Developing
While you develop I recommend using a test certificate. You can even install the certificate as a trusted publisher if you like. This will allow you to work on the project without knowing the real certificates password. Once you are ready to deploy then you can create the real certificate and deploy in a trusted manner.
Signing the Manifest?
Ok, here is where the really confusing stuff happens. This is going to get really really hard. Did I scare you? Oh well. This stuff is actually quite simple, but it is a lot to go through. I do promise you that once you go through this a couple times, you will be able to do everything in this document in a matter of minutes. It just takes a lot to explain it in detail. I will do my best. The following is an explanation of how the digital signing works and why we need it. Once you understand that, then I’ll go through how to do all the wacky junk we just explained. So …. On with the junk.

Certificates
Most of the articles you will read talk about getting a certificate from a trusted authority (like Verisign, or Thawte). If you are planning to deploy your application in your intranet (like I am) and your remote users will have access to your local network (your remote users VPN into the corporate network) like mine do. Then you really do not need to purchase your certificates. What you will need is a Certificate Authority (CA) installed within your domain. You will also need to run the CA on Windows Server 2003 Enterprise edition. Without Enterprise edition you will not be able to make the needed templates for use with ClickOnce. I installed my CA in a VMWare virtual machine but you can use a spare box (I just didn’t have one readily available). Installing a CA is outside the scope of this article, but I will give you an abbreviated version that worked for me. Make sure you check with your Administrator to see if this is the correct setup on your network. Ok, I warned you! You get to the CA installation from the Add Remove Programs and click the Add Remove Windows Components button on Windows Server 2003 Enterprise Edition.

Creating your own CA

We already had a CA on our network so I made this a subordinate CA. Your administrator will have to make sure that your CA is trusted as a Root

Creating a template that works!
Then you can create a new template for the CA.

Some names have been hidden to protect the innocent. As you can see from the above, the CA already has a Code Signing template (you may have to add it manually to the list of available templates). The problem with this one is that the private key is marked as not exportable. We will need the private key information to create one of the files we need for ClickOnce. There is no way to edit the Code Signing template. However, you can create a copy of it and change whatever you need on the copy. Then you can use that new copy to create what we need. To do all this mumbo jumbo you will need the Certificate Templates snap-in.

Here is a look at the existing code signing template (ignore the one I blocked out, it was requested by my employer).

Notice that some of the icons are grayed out. This is because they are not editable. We can only edit the new type of certificates that we make. So to do that, just right click the Code Signing template and duplicate it.

This is where we can change the things we need. Duplicating the template opens up the Properties of a new template dialog box. The first thing to do is change the name and how long the certificate will be valid.

Then click the Request Handling tab. This is where we tell the template to allow exporting of the private key.

Then just click ok to add the template.

What we just did was created a certificate template. That means that once we add this template to our server, you will be able to request a certificate based on this template. This certificate will then be applied to our manifest, digitally signing it to prevent tampering. So next we add the certificate to the CA.
 

Adding our new certificate to the CA
All we have to do is right click our Certificate Templates folder in our CA (not in the Certificate Templates snap-in, this time it’s back in the actual CA snap-in in the templates folder). Select Certificate Template to Issue.

In the list provided, select the template that you just created.

Now restart your CA service and you are ready to use the new certificate!

Certificate Files

What the heck is a .cer and a pfx file?
A .cer file is a certificate file. It may or may not contain an exportable private key (ours will). The pfx file is a private key file we can use in ClickOnce to sign our manifest. While there is a TON more to tell about certificate files, I want to keep it simple. People seem to get overwhelmed, so I am going to keep it very simple. You only need to know that we are going to sign our manifest with the .pfx, and we are going to use the public key out of our .cer to make our clients trust us as publishers.

What is a publisher and who is the root?
One of the most common questions I get is, “I don’t understand the whole root and publisher thing, can you explain it?” In a nutshell, there are three players involved in a trust situation. Imagine that I am your friend. You trust me implicitly. If I give you some software and tell you that it is safe to install, then you would trust me (hopefully). However, if you just met somebody in a back alley and they told you to install some software would you trust it? How about if that same person told you they signed it, would you trust it then? The answer should be a resounding NO! You don’t know that person and you cannot trust that just because they say it’s ok that it really is. Even though they signed it, who are they to you? Get it? Now if they gave me the software and I told you yes it’s ok to use, then you once again could trust it.

This is exactly how all this stuff works. The thing that gets confusing is when you are the CA, the developer and the client (when you test the application). To keep things straight, as you do each step you should imagine yourself working for some other department. The CA is the one you trust. Your Administrator in your environment has configured your network and all of the computers on it to trust the CA. This certificate should be visible in the Trusted Root Certificate Authorities folder in your local client machines certificates snap-in. If it isn’t talk to your admin and make sure it gets propagated. If you installed a subordinate CA your users will only need to trust the main CA as long as everything is configured correctly.

Notice in the Trusted Root Certificate Authorities folder is certificates for Verisign and other trusted root certificates.

These are your friends in the explanation above. If any root certificates in this list say software is safe to install, then your computer will trust them. Now, we are a trusted root as well (well at least the CA is).

What happens if we are not trusted?
We do have the ability to sign our manifest with our Code Signing template that we created and deploy the files using ClickOnce. The problem is, that if we are not a Trusted Publisher, the end user will be prompted with a warning:

While this dialog box would normally be ignored by most users, it really should never be seen. If I want to deploy software within my company, I should be trusted on the network and on the client machines. We are going though this portion of the document, to get rid of this warning dialog box. Plus it’s really cool to see this work as advertised!!

The next thing we want to do is to make ourselves a trusted publisher. That is, we want to tell our computer, that some developer is trusted by some root certificate (our CA). We are now the back alley guy who is looking for a trusted friend to tell everyone on our network that we can be trusted. In Certificates snap-in under Computer, you can see a folder called Trusted Publishers. We (as developers) need to be in that folder for windows to trust our install and not warn us. This is as easy as putting the certificate into the folder, but who is going to do that? For the sake of keeping it simple, we will do that part manually for this portion of the article. At the end of this article however, I will describe how to push this trust out via Group Policy and make this a seamless hands off operation (with the help of an Administrator friend).

Generating a Certificate
Now to make sense of all that setup we just created. Time to create a few files. Open up internet explorer and go to your CA. It should be at http://yourCAserver/certsrv/.

Click Request a Certificate.
Then click Advanced Certificate Request.

Next click Create and submit a request to this CA.

Select the certificate template we created earlier. Make sure the Mark keys as exportable is selected.

Click the submit button.
You should then see this page:

***If you do not see this page, you may have a CA setup to manually issue certificates, all you have to do it go into the snap-in for the CA and right click the certificate in the pending folder, and issue the request. Then go back to the website, and check the status of an existing request. You will find the certificate waiting for you.

Click the Install this certificate link.
Your certificate is now installed in your personal certificate store.

We need to get two files from this certificate, a .cer and a .pfx. First for the pfx.

Exporting the private key
Open the certificates snap-in for the current user.

In the right hand pane right click the certificate you just installed and select Export. The following wizard will display:

Click Next.

We want to export the private key as we will need this later.

Click Next.

Leave everything the same for the export file format page of the wizard.

Click Next
Type and confirm a password for the private key in the next page of the wizard.

Click Next.

Give a path for the location of the saved private key file.

Click Next.

Click Finish. The private key file is now in the specified path.

Exporting the public key
This process is the same as the private key. I will display the exceptions here, but just follow the Export private key instructions for the most part.

On the Export Private Key page of the wizard, choose No.

On the export file format page of the wizard, select either DER, or Base-64 options as they will give us a file with the .cer extension.

Save the file with a .cer extension.

You now have the two files you need. Although it is a lot to document, once you understand what you are doing, and have the needed items installed in the CA, you can request a certificate and extract the needed keys in a minute or two.

After all that, what do I do with these stupid files?
Whew, that was a lot to explain, but hopefully you are with me. Here is a quick re-cap of what we have accomplished this far. We setup our code for ClickOnce (more of that is needed now); we installed our CA which is a one time thing. We created a reusable template for creating a Code Signing certificate with an exportable private key (.pfx file). Lastly, we exported the public and private keys from our installed certificate in our store.

The next thing we need to do is to setup our Trusted Publisher on our client machine. Remember this is where we switch hats. We are now acting as the end user (client). Copy the .cer file to the client machine. In the client (I am using a VMWare virtual machine; you can use your workstation if you need to), open the Certificate store for the computer (snap-in). Right click the Trusted Publisher folder. Choose All Tasks -> Import.

In the wizard, navigate to the .cer file and finish out the wizard with no other changes. What we just did, was told the client computer that any software pushed by the publisher described in the certificate should be trusted. The certificate is signed by a trusted root because the CA that signed the certificate is already trusted (we made sure of that before).

To see the certificate, you can double click the certificate (either the .cer file, or the entry in the certificate store). It will show you the details:

Great! Now we are trusted.

Sign and Deploy
Signing and CAB
We are about to sign the manifest with our certificate. The problem is that since we are using CAB, the shell project does not contain our smart parts or any other references for that matter. When deploying a ClickOnce application the ClickOnce output generated by Visual Studio includes the files and references in the project being signed and deployed. This means that in a CAB environment you either have to reference your modules in the shell, or modify the manifest and re-sign it when you are done. I prefer not to add the references because one of the benefits of using CAB is that it’s loosely coupled and I want to preserve that. You can make your own decision. Adding the references is only for the purpose of telling Visual Studio that you want to include the dlls in your bin directory and that you want ClickOnce to include the files in your manifest. Again, we will do it all manually.

Deploying the Shell
Let’s go ahead and deploy the shell. This will not include any modules. We will add those later. In the shell project, select the Signing tab in the project properties. In the following diagram, I have a test certificate installed. We will be replacing this with our Code Signing certificate.

Assigning the Code Signing Certificate
Click on the Select from File button. Navigate to your .pfx file. When prompted, enter the private key password.

After clicking Ok, you should see your Code Signing certificates information in the certificate area.

Finally Deploy the application
Ok, now build your project and then to deploy it, either select the Publish tab, or choose Publish
on the Build menu. This will bring up a wizard. After the first time, you can just click finish right away, but we will go through it here so that you understand the steps.

This is the location from the publish tab itself, it’s just giving you one last chance to change your mind. I am using a file share here, but notice that you have examples of other types of deployment options.

Click Next.

Leave the default and click next.

The main difference is the shortcut on the start menu. This works well for me. You can choose which ever one you want. Again, this is copied from the Publish tab.

Ok, here we go!! Click Finish.

Your project will build and then publish to the deployment folder.

Errors
If you get any errors like the following:
Could not find a part of the path ‘C:\…\bin\Debug\Shell.publish\Shell_x_x_x_x’.
The easiest way to move on is to just bump the revision number up on the Publish tab and republish.

Test the Deploy
Now we are going to install the application, remember that this is just the shell. Go to your client (end user) environment (my VMWare machine). Navigate to the share (Start -> Run).

In the window that opens you will see something similar to the following:

Double click the Shell.application file. This will launch the click once install. First you will see the application check the manifest on the server and determine if it needs to install anything locally.

For us this is the first time, so it will download the program and run it. Hopefully all goes well up to now. If you notice (or didn’t notice) it did not ask you to ok the publisher. We are all trusted now!

Errors
If you see errors, you will want to do a couple things:
Run the exe in the bin directory. Make sure this an actual ClickOnce problem and not a bug in your executable.
Look in the deployment directory (C:\1DeployPROD\Shell_1_0_0_4). Compare the files to those in your bin directory. All of the files in the folder will have a .deploy extension, but the files are unchanged (you could remove the .deploy extensions to test the .exe).
If files are missing, which is likely when using CAB, then you’ve found the reason for the error. You can either add the files in the publish tab (application files button). Or you can add them manually when we add the modules and their dependencies. The important thing to realize is that the application did deploy and did try to run (albeit with errors). The ClickOnce and signing portion really did work.

Adding the Missing Files
Whether you had errors running, or just didn’t see your modules from CAB you will need to add the missing files. The steps are simple. Just modify the manifest to add the missing files, and then re-sign the manifest with our certificate.

There are a couple different ways to add files to the manifest. You can use the tool that comes with .net called Mage. It has flavors for command-line and GUI. Mine is installed in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin. Using this tool has a couple limitations, and I have stumbled upon a better tool.

Tools to Manipulate the Manifest
If you want to know more about the options check out the ClickOnce Community Resource Kit. It was put together by Brian Noyes. He is an authority on this stuff (he even wrote the ClickOnce whitepaper for Microsoft). Get the ClickOnce Community Resource Kit here:  http://www.codeplex.com/smartclient/Project/FileDownload.aspx?DownloadId=5060

In that kit there is GREAT pdf showing you how to do all kind of things with both Mage and his tool (which comes with the Resource Kit). My examples will use Brian’s tool called Manifest Manager Utility.

To continue, please download and compile the Manifest Manager Utility.

Fire the Manifest Manager Up
Before you start, you need to find all of the files you need to deploy. I would suggest a manual run, because many of the problems I have had with CAB deal not with ClickOnce, but with missing files. Create a directory and copy all of the files in the shell bin folder to this new directory, then copy the module dlls and referenced files from their bin folders to this new directory. When all of the needed references and files are in there, run the shell.exe from the firectory and test your application. If it doesn’t work in there, it won’t work when deployed via ClickOnce. Ok, you’ve been warned!!

We will go through two different iterations to keep things clear. The first example will simply add the files we need to the manifest and sign it. The second example will give us the ability to run side-by-side versions of the same ClickOnce deployed application.

Adding Missing Files
Run the Manifest Manager Utility. You will see the following screen:

Click Open.

In the Open File dialog box, choose the deployment manifest file. This is the file that has a .application extension, it is in the root deployment folder and does NOT contain the version in the name. For my example it looks like this:

Click Open.

You will now see the files contained in your manifest. All we have to do is click the add button:

When using CAB, all of your files should be in the projects bin folder (especially if you used the Guidance package to create your projects (I do). If not, don’t worry, you will just have to get your files from many locations (each modules bin folder).

Finally Adding the Files
I will navigate to my bin folder and select the missing files.

I can’t forget CSLA (thanks Rocky)!!Don’t forget this one if you use Enterprise Library:

Click Ok.

Next you are provided with a destination location dialog:

Select the location where you want these newly added files to live. I prefer to keep them with the other files already in the manifest for the version that I am about to push, so I will put them here:

Click Ok.

Now the list of files should match the manual run test you did earlier. If everything is ok, then all we need to do is save and sign the manifest. So just click the Save button. You will see the following dialog:

Point the path to your .pfx file that we created so long ago.
Type the password for the .pfx file.
Click Save and Sign.

That’s it!

Testing It All Out
Go to your client machine environment and run the application from your share. Mine looks like this:
file://jnoble/DeployPROD/Shell.application

You should see:

Then this:

(If you saw a dialog asking you anything, then your certificate is not trusted).

Then the application should run.

Viola!

Side by Side Execution
Earlier I spoke of running different version side-by-side. What I mean by this is I want a development version (beta) and a production version (RTM) installed on my machine. If we don’t do anything and just deploy two versions to two different folders, the client will assume that they are the same version and overwrite the last one each time you run. This is bad, especially if you want icons on the start menu for each of them (offline mode of ClickOnce).

Telling ClickOnce They Are Different
Remember back in the Setting a Publishing Point section of this document that we setup two deploy folders? Our folders were for production and development. We have only been using production up until now. We will leave the production one alone since we already have it deploying via ClickOnce and it’s good to go. What we really have to do it tell ClickOnce to treat our development version as if it’s a totally separate application. Here is how we do this:

Set the deployment location.
Set the name to development in ClickOnce.
Rename the manifest file.
Change the Application Identity in the deployment manifest.
Change the Deployment Provider in the deployment manifest.

Sounds tricky huh? Well it isn’t. As a matter of fact only two changes are in Visual Studio. The rest is in the Manifest Manager Utility.

So, go back to the shell and open the Publish page of the project properties.
Step 1: Set the deployment location to our development share.

Step 2: Click the Options Button. Change the product name to show a new name. This is the name that will show up on the Start Menu.

Click Ok.

Build the application.

Publish the application.

Step 3: In Windows Explorer rename the manifest file to a unique name, but remember the name. I used this:

Now fire up the Manifest Manager and open your new manifest. (Shell-DEV.application in my case).

Step 4 & 5: Change the name in the Application Identity and the Deployment Provider.

Now just add the missing files and sign and save the manifest (shown in the previous example labeled Finally Adding the Files).

New Install

Background
Ok, so we know what to do and are all set, but how are we going to push out this trusted publisher to the machines on our network? While I am sure that there are many creative ways to do this. I came up with one that works for me. I hope it works out well for you too.

All I really wanted to do was to install my trusted certificate in a client machine. Later I would add a desktop icon to the desktop, but I’ll leave that for another blog article. I decided to have a friend create a group policy in Active Directory and that we would push an installer.msi onto the client machines on our network. All I had to do was create an installer that would install our certificate (.cer file) into the trusted publishers store on the client machines and the group policy would push the software to the client and run the installer. Perfect! But how do we do that…. After much research (and trial and error). We came up with the following:

Creating the Installer
In Visual Studio add a new Setup Project (under Other Project Types, Setup and Deployment).

Setup the Setup
Now we have to add the certificate file to the installer.

Select your .cer file in the Add Files dialog.

We will place the .cer file in the System32 folder on the clients machine because I don’t want them to mess with it and most people don’t even look in there. If they do find it, it’s fine because it’s just a public key file. You can’t sign with it.

Adding the System Folder
We have to add the System folder to our installer. Double click your .cer file in the project and then right click the File System on Target Machine icon.

Now select the Application Folder and drag the certificate icon from the Application folder to the System Folder:

So that takes care of deploying the certificate to the client. Now all we have to do is have the installer put it in the trusted publishers store.

Trusted Publishers Installer Class
Add an installer class to your project

Now delete the class1.cs and add an installer class to the project.

Next add a committed event to the class. This will get called by the installer when it enters the commit phase of installation:

Add the following code to the Committed event handler:

using System.Security.Cryptography.X509Certificates;
private void ApplicationInstallerHelper_Committed(object sender, InstallEventArgs e)
{
 X509Certificate2 certificate = new X509Certificate2(Environment.GetFolderPath(Environment.SpecialFolder.System) + @"\MyCompanyApplication.cer"); X509Store trustedPublisherStore = new X509Store(StoreName.TrustedPublisher, StoreLocation.LocalMachine);
 try
 {
   trustedPublisherStore.Open(OpenFlags.ReadWrite);
   trustedPublisherStore.Add(certificate);
 }
 catch (InstallException ex)
 {
   // write to eventlog here.
 }
 finally
 {
   trustedPublisherStore.Close();
 }

This code creates a new certificate object and loads our certificate from the file. I use the Environment.GetFolderPath() function to get the actual path of the system32 folder on the client machine.

Next I create a Certificate Store object and set it to the Trusted Publisher and Local Machine (as opposed to the user scope). This will install in the proper place for trusted publishers on the client machine.
Finally I just open the store, add the certificate and close the store.

Installer Meet Installer Class
We have all that we need to work except there is no communication setup between the installer class and the installer. To make this work it takes two steps.
Add the installer class output to the installer project.

Add custom events to the installer project so that each phase of the install will notify our installer class. (We have code in the committed event that our class will react to).

First add the installer class output to the installer project.

Select the installer class:

Make sure primary output is selected.

Next right click the application installer project and select Custom Actions from the View menu.

Now right click each folder in the custom actions and add a Custom Action

Select the Application Folder select the Primary output from your Installer Class and click Ok.

Do this for each folder. You should be left with the following:

*We only really care about the Commit Action, but I like to add these because if I ever need to react to different events in my installer class, it’s all hooked up for me.

That’s it!

Test it out
Now compile the Application installer and you can run the .msi file it creates on your client to automatically install the certificate in the Trusted Publisher store.

Once you verify that it works (just check the snap-in to see your certificate in the Computer Store’s Trusted Publisher folder). Then we can give the installer to the group policy. The group policy will then push this out and run it for us.

Ty-ing It All Together
The rest of this article was written by Ty Ryan. Ty is a Systems Administrator and VMWare expert. He enjoys long walks on the beach and quiet evenings with his laptop.

Here are his instructions for adding this .msi to Active Directory Group Policy.

Assigning Applications via GPO’s

In this document we are going to discuss how to create Group Policy Objects in order to publish or assign applications create by OneClick. Only use this technique to deploy certain types of applications. Specifically, you can install Windows Installer packages (.MSI files), Transform Files (.MST files), and patch files (.MSP files).

Providing the application to assign

The very first step is to create an MSI which will be pushed via Group Policies Objects.
To create, manage, backup, import, or report group policy settings I would suggest using Microsoft’s GPMC (Group Policy Management Console) which provides a UI to better manage all GPO’s.
You can go directly to Microsoft’s site to get GPMC by clicking here and if you would like more information on managing group policies, follow this link.
To create your group policy right-click on the Active Directory OU you wish to apply or test it and click Create and Link a GPO Here…

Now, provide a name for your GPO and click OK.

Go ahead and right-click on the new GPO and click Edit.

You will now be able to modify the settings necessary to install ClickOnce applications remotely.
Click on the “+” of Software Settings under User Configuration, then right-click on Software installation, New, Package…

Select Assigned to install the application the next time the user logs into Windows. More info about the difference between Published or Assigned applications can be found here. Be sure that the application to be assigned is in a centrally located share easily accessible by domain controllers and users.
Right-click on the newly created software installation assignment and click Properties.

On the second tab, Deployment, be sure to select Install this application at Logon and then click OK.

If the application to be installed requires Local Administrator privileges for a successful deployment, then elevated privileges will have to be enabled within the GPO used to assign the application at next logon. This can be accomplished by enabling Always install with elevated privileges located under Computer and User Configuration, Administrative Templates, Windows Components, MSI Installer.