Installing Windows Phone 7.1 SDK via .ISO using .MSI and Group Policy

Normally, if were installing the Windows Phone SDK 7.1 onto a single machine you do it through the web installer located here:

https://www.dreamspark.com/Product/Product.aspx?productid=26

or via Microsoft Download centre at https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27570

However, if you need to install it on a disconnected machine (VM image) or deploy the SDK to a number of machines within a lab or cluster  it’s helpful to have an .iso of the installation media to install from.

Microsoft also provides a download for the .iso as well. You can get it from here https://go.microsoft.com/fwlink/?LinkID=226694

Installing the Windows Phone SDK via ISO

Phone SDK consists of many packages/products and all these are installed on User’s machine as part of Phone SDK installation. Some of these packages are Emulator, XNA, Blend, Visual Studio Add-in for VS Ultimate, etc. Each individual package has got it’s own MSI.

When you extract the ISO (let’s say in dvd folder), you will find Setup.exe at the base level (dvd folder). This is a chainer and invokes all the MSIs one-after-another, the same way you mentioned below. Anyone who wants to install through ISO, should double-click Setup.exe and installation will start. It also gives you the option of Silent install same as MSI (option /q) and thus can be used through automation scripts as well.

WCU\WindowsPhone

This is an important folder which contains most of the package MSIs but they should not be invoked separately. The complete installation is dependent on the sequence in which these MSIs are installed.

Uninstall:

After Uninstall, only Expression Blend entries are left back and this is known. Blend is a separately installed product and many Universities may  therefore have this previously installed, as such we decided not to uninstall Blend in case a licensed version is present on the machine and our uninstall causes any problems with previously installed products.

Summary:

In short, consider Setup.exe as your master MSI and use it in your scripts, everything should work.

Creating an bundled MSI file (This may be requirement for some institutional desktop images)

The creation of MSI is primary used for legacy applications that were written prior to msi technology, and may be unreliable as the "snapshot" technique does not take into account existing software dependencies.

Windows does not natively contain the necessary tools for you to create your own MSI files. Instead, you will have to rely on a third party MSI creation tool. There are several good tools available for free. Two of the more popular choices are MAKEMSI (https://dennisbareis.com/makemsi.htm) and WinInstall LE 2003 (https://www.ondemandsoftware.com/freele.asp).

The reason why .MSI files are the preferred installer package for Windows is because of the file format’s capabilities. When you install or uninstall an MSI file on a machine running Windows 7, Windows creates a system restore point. Furthermore, MSI files allow the application to be “self healing”. I’ll talk more about this later on, but basically this means that if part of the application is damaged or removed, then Windows has enough information to replace the damaged or missing parts. Finally, MSI files allow the system to automatically perform a rollback to its previous state if an installation should fail.

With MSI files having so many capabilities, it should come as no surprise that MSI files tend to be a bit complex. MSI files are actually database files with information pertaining to every file and setting that the application installs or modifies. Because of this complexity, most of the MSI file creation utilities require you to do at least some scripting when you create an MSI file.

WinInstall LE requires you to have a machine with a clean Windows installation and network connectivity. The software then takes a snapshot of this machine and saves the configuration image. You would then install the application that you want to create the MSI file for and take another snap shot. WinInstall would then compare the snapshots and use the differences between the two images to create an MSI file and the corresponding installation package.

This method is a little time consuming, but is far less tedious than writing scripts. Another advantage to using this method is that it is possible to install multiple applications on to the clean machine prior to taking the second snap shot. This means that you can create a single MSI file and installation package that deploys multiple applications.

Publishing and Assigning Applications

Now that you know how to create an MSI file, there is one last concept that I need to talk about before I show you how to deploy an application thorough the Active Directory.

As you may already know, in an Active Directory environment, group policies are the main component of network security. Group policy objects can be applied either to users or to computers. Deploying applications through the Active Directory is also done through the use of group policies, and therefore applications are deployed either on a per user basis or on a per computer basis.

There are two different ways that you can deploy an application through the Active Directory. You can either publish the application or you can assign the application. You can only publish applications to users, but you can assign applications to either users or to computers. The application is deployed in a different manner depending on which of these methods you use.

Publishing an application doesn’t actually install the application, but rather makes it available to users. For example, suppose that you were to publish the Windows Phone SDK tools. Publishing is a group policy setting, so it would not take effect until the next time that the user logs in. When the user does log in though, they will not initially notice anything different. However, if the user were to open the Control Panel and click on the Add / Remove Programs option, they will find that Microsoft Windows SDK is now on the list. A user can then choose to install Microsoft Windows SDK on their machine.

Assigning an application to a user works differently than publishing an application. Again, assigning an application is a group policy action, so the assignment won’t take effect until the next time that the user logs in. When the user does log in, they will see that the new application has been added to the Start menu and / or to the desktop.

Although a menu option or an icon for the application exists, the software hasn’t actually been installed though. To avoid overwhelming the server containing the installation package, the software is not actually installed until the user attempts to use it for the first time.

This is also where the self healing feature comes in. When ever a user attempts to use the application, Windows always does a quick check to make sure that the application hasn’t been damaged. If files or registry settings are missing, they are automatically replaced.

Assigning an application to a computer works similarly to assigning an application to a user. The main difference is that the assignment is linked to the computer rather than to the user, so it takes effect the next time that the computer is rebooted. Assigning an application to a computer also differs from user assignments in that the deployment process actually installs the application rather than just the application’s icon.

Deploying Applications

Setting up the actual deployment is simple. The biggest thing that you must remember is that the MSI file and the corresponding package must exist within a network share, and everyone must have read permissions for that share.

To perform the deployment, open the Group Policy Editor. To publish or assign an application to a user, navigate through the group policy console to User Configuration | Software Settings | Software Installation. Now, right click on the Software Installation container and select the New | Package commands from the shortcut menu. Select the appropriate MSI file and click Open. You are now asked whether you want to publish or assign the application. Make your selection and click OK.

The process for assigning an application to a computer is almost identical. The only real difference is that you would use the Software Settings | Software Installation container beneath the Computer Configuration container rather than beneath the User Configuration container.