How to Deploy Windows Form Application With Database

In my previous article I explained how to deploy an MSI package with System Center Configuration Manager 2012 (SCCM 2012). Today I will describe the deployment of scripted application installation to illustrate some differences.

• Author
• Recent Posts

David is an author and consultant, working for Endurance IT Services in Virginia Beach, Virginia, specializing in Microsoft enterprise systems and Business Process Automation.

As with the previous article, the goal of this is to provide a concise, straightforward procedure for deploying an application. It is important to note that since there is no single "package" for the Configuration Manager system to query, you will need to specify a lot of detailed information if you want the reporting features to reflect it accurately. That is one of the main benefits of using an .MSI or .EXE installation package.

Background ^

Many businesses develop custom "applications" in-house which aren't really applications at all. For example, grouping an executable along with custom files and a custom shortcut and giving it a custom name. One that comes to mind was a Microsoft Access .MDB database file, along with an Excel Spreadsheet, and a custom shortcut which, when combined, were used for entering and tracking special mechanical parts for a construction company. The combination was referred to by all employees as something like "Parts Master" (my nickname, not theirs).

In that environment, if you tried to query computers remotely for which ones had "Parts Master" installed, you wouldn't find any. You'd find traces of Access and Excel, and maybe a shortcut file, if you looked for it. This type of installation is very commonly handled with a script, and deployed using a product like Microsoft System Center Configuration Manager. You could repackage many scripted installations into a single .MSI package using a product like Flexera Software's InstallShield AdminStudio. However, many businesses do not have such a product on-hand, or in many cases the amount of effort required to repackage them might be overkill.

For this article, I am going to deploy this bundle which the users refer to as "Parts Master". It includes a Microsoft Access Database ".accdb" file, and a Microsoft Excel ".xlsx" file. In addition, the script will adjust folder permissions on the target folder so that users can open and edit the files within it. Finally, copy/create a custom Start Menu shortcut to launch the Access database using a shortcut name of "Parts Master".

The script language is not really that important. I chose .BAT (using a .CMD extension) since it's one of the most common types in existence. You can just as well use a script file written in any language that will run reliably on your target devices.

Basic process ^

1. Create/Edit/Test the Installation Script
2. Create a new Application
3. Create a Deployment
4. Monitor the Deployment status

I'm not going to spend time on step 1 since this is really about the deployment aspects, so let's dive in.

Create a new Application ^

1. Store the source files in a folder which is shared over the network. (You can only select content for making an Application deployment if it can be accessed via a UNC path reference, so drive letters are not allowed.)
   
2. In the SCCM 2012 Administrator Console (hereinafter referred to as the "Admin Console"), expand "Software Library" in the left-hand panel. Right-click on "Applications" and select "Create Application". You can also click the "Create" button at the top-left end of the ribbon menu, and click the "Application" sub-option.
3. Select "Manually specify the application information", and click Next to continue.
   
4. On the "General Information" page, fill-in the form fields to describe the application as best as you can. The more information you provide, the more it can help with future tasks. Note that this is not specifying the script itself, but rather it describes the application. When finished, click Next to continue.
   
5. On the "Application Catalog" page, specify the language and localization options. If you have online documentation to refer your users to, you can enter the URL or UNC path for providing access to it. You can also provide additional information if desired, such as Localized description, and keywords for catalog searching. Click Next to continue.
   
6. On the "Deployment Types" page, click "Add".
7. On the "General Information" page of the Deployment Type, select "Script Installer" from the "Type" drop-down list, and click "Next". Enter the Name and (optionally) Administrator comments, as well as selecting the default Language options. Click Next to continue.
8. Specify the UNC path for the "Content Location" field, then click "Browse" to locate and select the installation script file.
   
9. On the "Content" page, click Browse and select the script file to use for the Deployment. If you have an "uninstall" script (and you really should), specify that as well. When finished, click Next to continue.
   
10. On the "Detection Method" page, if you want to create a detection rule, click the "Add Clause" button, and specify the properties to tell Configuration Manager whether or not the application has already been installed on a given client. In this example, I want to check for the existence of the "hwinventory.accdb" file in the default folder path. This step is not mandatory, but it is usually a good idea to instruct Configuration Manager on how to detect custom application bundles so it can track inventory accurately. When finished, click "Next" to continue.
    
11. On the "User Experience" page, specify how you wish to deploy this application (per user, per device or mixed). In the example, I chose to deploy to the Device (computer), and have it install regardless of whether a user is actively logged on or not. Click Next to continue.
    
12. On the "Requirements" page, you can specify any hardware or operating system requirements, however in this example I have no such requirements. Click Next to continue.
13. On the "Dependencies" page, I am specifying that the client needs to have Microsoft Access 2010 installed. This is so it can properly handle opening the Access database file which is the core component of this "application" bundle. I could also specify the Access 2010 Runtime client, or even the entire Microsoft Office 2010 suite, since there is an Excel spreadsheet included. When finished, click Next to continue.
    
14. Click Next to accept the confirmations and summary, and then click the Close button after the Application is created.
    
15. Once the Application is created, click on it and review its properties to verify everything is as you expect it to be.
    

Staging and deploying the content ^

The next step in the process is to make sure the installation files are placed where clients can access them when needed. Rather than repeat the same steps as in my previous article, I would rather just refer you to that for using the "Distribute Content" feature to copy the installation source content to the appropriate Distribution Point servers in your environment.

The Deployment process is the same as with a .MSI or .EXE application. You can make the Deployment "available" or "required", as well as having it install based upon a user logon or not.

From this point, you should now have an active Deployment which clients will begin evaluating and executing, as long as they are members of the target Collection and they meet any optional Global Conditions you may have set on the Deployment.

Monitoring the Deployment ^

Now that the Application is in Deployment, the next step is to monitor its progress. Click on the Monitoring section in the Admin Console, and select Deployments. From here you can view the current status of each Deployment and see successes and failures. You can also drill-down into each status indicator to view more detail if needed.

Subscribe to 4sysops newsletter!

Conclusion ^

One thing I would like to strongly recommend with regards to Scripted installations is to spend a little extra time making sure that your script creates a thorough log file. A typical .MSI package will create a very detailed log file, but when you are using a script, it's entirely up to you to handle that. The more detail you include in the log output, the better prepared you will be to troubleshoot issues that may arise during the deployment. Other than that, you should be ready to deploy!

How to Deploy Windows Form Application With Database

Source: https://4sysops.com/archives/how-to-deploy-a-scripted-application-installation-with-sccm-2012/

Share this post