Provide Feedback on this Broadcast

Note This document is based on the original spoken Support WebCast transcript. It has been edited for clarity.

Jack Davis: My name is Jack Davis and here at Microsoft I am a member of Visual Studio install team. Today we will be talking about the deployment of Microsoft® Visual Studio® 2003 through the use of Active Directory®. Since our audience is often fairly diversified, I would like to take a minute to describe a few of the technologies and products that will be discussed.

What we're talking about here is a method of doing deployment for Visual Studio 2003 from a centralized server to multiple client workstations (slide 2). This is primarily useful for development houses that wish to push Visual Studio 2003 to their development workstations, or for training and educational facilities where a trainer could actually push the software to his student machines.

I'm assuming that you have some familiarity with Visual Studio .NET directory services or Active Directory, Group Policy objects, the event logs, and the deployment through the MSI technology (slide 3). Active Directory, for example, is Microsoft technology that is available starting in Windows® 2000 Server. It can be used in larger network environments that require more than the use of a peer-to-peer network. In our case, we will be using it to select which computers our program will actually be installed on.

Visual Studio .NET 2003 is Microsoft's latest and greatest development tool. Natively it allows programming in Visual Basic®, Visual C++™, Visual C#®, and Visual J#®, and another 20-plus languages available.

The MSI is the Microsoft Installer. It has many outstanding features to assist in installing programs including resiliency (self-healing), repair, and transactional rollback. In our context we will be demonstrating the ability of the MSI to work in concert with the AD, Active Directory, to deliver programs to specific computers simply by virtue of them belonging to Active Directory domain. MSI also supports the ability to apply a modifying file, referred to as a transform; this is something that we will also demonstrate.

The GPO is a component of Active Directory that allows for granular editing of policies from an entire domain down to individual machines or users. In our case we'll be using the GPO to push out our deployment package. Internet Information Services (IIS) for Windows 2000 or higher is required for any Web development for Visual Studio .NET. While it's not a requirement for the installation and a remote IIS could be used, in most cases, a local IIS will accompany the installation of Visual Studio 2003. IIS is part of the Windows operating system.

If any Web development is planned, I do recommend that the IIS be installed prior to any Visual Studio 2003 install. Event logs are an indispensable tool for network administrators. They are often the best source for information, both good and bad, success and error messages for the computer system and applications. This is no exception in our case. If you're not already doing so, please review the event logs regularly.

Our agenda (slide 4): an overview of what Active Directory deployment can and cannot do for you, the minimum requirements for this installation, some step-by-step illustrations of the setup and installation, "heads-up" on potentially problematic areas, reference materials, and certainly my favorite part, question and answer.

Is it a mass deployment panacea (slide 5)? No. But the large part of the installation, namely Visual Studio and the MDSN Library, can be pushed out. If you are looking for Active Directory to perform the entire installation of Visual Studio from start to finish, you will be disappointed. There is work that is required outside of the main MSI deployment for Visual Studio .NET and the MSDN® Library.

There are other options for installing this product. They include the standard CD or DVD installations done at workstations; creating a simple flat image (a copy) of the installation media on a shared location and instructing the users to navigate to that location and launch the installation; and using deployment tools such as Systems Management Server (SMS) or other third-party deployment packages. Simplicity is often the best choice, so please measure the benefits carefully before embracing this Active Directory deployment.

Active Directory will install Visual Studio .NET 2003. It will install the MSDN Library, the help for the product. It should not be used for installing the prerequisites, including the Microsoft .NET Framework. It should not be used for the installation of IIS. So please measure the additional complexity against your objectives.

Minimum requirements (slide 6): We need Active Directory on Windows 2000 or Windows Server™ 2003 domain. It is beyond the scope of this presentation to cover creation or the setup of Active Directory. We will need a share on the server that is available to the client computers with 3.5 gigabytes (GB) of free space minimum. We also need administrative rights on the server and, of course, the client computer should have the minimum hardware requirements for Visual Studio .NET 2003 and the MSDN Library installation, and be part of Active Directory.

In this presentation (slide 7), we will assume that the client computers already have Visual Studio 2000 prerequisites installed. These are available from the prerequisite CD. While some, but not all, prerequisites could be deployed by Active Directory, it is not appropriate for an installation, because of timing issues. Any Web development, of course, will require IIS, which would be version 5.0 or later. IIS can be installed after the fact, but more work would be involved. I recommend it to be installed prior to Visual Studio Active Directory, just like the prerequisites.

So, let's create an admin image (slide 8). Unlike the conventional CD or DVD installation, the installation source or the administrative image must be modified. This modification is made with an MSI transform file and is available at this link. Make sure that this next statement is entered correctly. Failures will be silent and can prevent Visual Studio .NET IDE from opening successfully. By the way, these reference links are presented again at the end of the presentation.

In this example (slide 9), the transform file is placed in the target folder. This simplifies a later step when referencing the administrative images, since both the MSI and the transform will be in the same folder and, therefore, on the same share. Notice the use of the TARGETDIR. The creation of the administrative image will not prompt you for the destination location as some other installation packages do. If you fail to specify the TARGETDIR, you will get quite a few files in your root folder. That's not a good thing.

Modifications to the installation (slide 10) such as selecting or excluding individual components (for example, selecting different programming languages and not others), is not available. This deployment is an all-or-nothing proposition. Without the transforms, Visual Studio .NET installation would stop the installation and require the running of the Setup.exe.

Please notice in the second bullet item that there is no transform being used for the MSDN admin image. In fact, if the /qb and the TARGETDIR are excluded from the MSDN statement, you will be prompted for this to enter a target directory. Either method is acceptable; I am simply using the flags on the command, because they were required for the previous Visual Studio administrative image creation. As a result (slide 11), we should now have two admin images on the C:\Applications folder that include Visual Studio .NET .msi package and the transform (.mst) file, as well as the second image, which is the MSDN Library (Msdn.msi).

The last step to create the admin image — these steps should be very familiar to anyone who has created shares with read permissions (slide 12). There is nothing unusual here. You create the share with at least read permission for the client. Select and then right-click the folder, click Sharing and Security. On the Sharing tab, click Share this folder, and establish the share name. Click the Permissions button, and verify that the minimum rights are selected.

Also verify that the NTFS file system permissions are correct. Click the Security tab and give the client a minimum of read permissions. Please keep in mind that the permissions we are discussing here are for the deployment only. The permissions required to successfully develop within Visual Studio are a story for another WebCast.

Having completed the creation of the admin image and having set the security and the permissions, we can move to the Group Policy object (GPO) for the OU (slide 13).

Besides the hardware requirements, all client machines will require the prerequisites to have been installed prior to Active Directory, including the .NET Framework 1.1. Judging from our support calls, this is a big deal. It is very apparent that the installation would be much easier if the prerequisites could be incorporated into the main installation.

The installation of IIS is also an issue, but being part of the operating system, it is most likely that it will require a separate step before Active Directory deployment. I'd like to take this opportunity to share something with you from our Visual Studio program manager, Kevin Morrill. This is something in the testing phase, since the product is still in beta, and might be modified before release.

The product, which is code-named Whidbey, will have all of the present prerequisite requirements built into the main installation wizard and have Active Directory fully integrated. I'm sure that you'll have to agree with me that this is some very good news and a welcome change.

Using or creating the appropriate OU on the domain controller server (slide 14): To do so, click Start, click Control Panel, double-click Administrative Tools, and then click Active Directory Users and Computers. To create the OU, right-click the domain node. Click Create, click New, and then add the new organizational unit. Give your OU an appropriate name or, again, you can also use a preexisting OU.

At the GPO, choose the installer package (slide 15). To do so, right-click the resulting OU, click Properties, and then click the Group Policy tab. Click the New button, and enter an appropriately named GPO.

Edit the GPO (slide 16). Select the GPO and click the Edit button.

This deployment will work only per computer, not per user (slide 17). The "per user" installation is not recommended, because network performance issues, and also because it has not been tested.

Navigate through the Computer Configuration node to the Software installment node and highlight it in the left pane.

Select and then right-click Software installation, point to New, and then click Package (slide 18). In the resulting dialog box, enter the UNC share location, not the actual local location. If you do not use the UNC (Universal Naming Convention) share, you will get a warning message indicating that the client might not see the same location. Please heed this warning.

By rights, the only appropriate browse selection in this particular dialog box is through My Network Places. However, depending on the size and the responsiveness of your network, you might find it quicker simply to type in the share name.

Locate the target .msi file and finish by clicking the Open button (slide 19). Please have patience with the next few dialog boxes to come up, particularly with this size package. They will take some time and it is not always clear that the process is busy.

Click Advanced in the resulting dialog box (slide 20). This will allow us to add the transform in a later dialog box.

To apply the transform (slide 21), click the Modifications tab in the resulting dialog box. Click the Add button. As with the previous step, add the transform file from the share location. The result should be similar to what is shown here on this screen. And finally, click OK.

The admin image has been created (slide 22). The GPO for the OU has been added. If the appropriate computer accounts are not in the OU, then add them. Now if a computer is restarted or added to the OU, the screen that will appear before the log on should show the managed installation occurring like this (slide 23).

The event logs (slide 24) will also show Visual Studio .NET installation success, the same for the MSDN Library (slide 25), and for the resulting menu items (slide 26). Okay, that is enough basking in our success.

Let's review what we have done (slide 27). We've created admin images. We checked the statement for accuracy. Both extra white spaces and case sensitivity of the parameters can cause unexpected results.

A mistyped ID (PID) will allow for the installation to succeed, but the integrated development environment (IDE) for Visual Studio will not remain open. We then added the package to the GPO for Visual Studio .NET, selected Advanced, and modified with the transform file. We used share names so that the clients know where to find the administrative images, and then we simply restarted the clients.

Some additional resources (slide 28): The white paper was produced by our developers and is very well done. I would also suggest not rushing through the download site. There is also some very good additional information here. We will, of course, continue to keep these sites updated with the latest news.

That, ladies and gentlemen, is my story today. I have another teammate with me today, Dennis Schmidt, who is a senior support professional on both our MSI and our Visual Studio Install team. Together would love to field some questions that you might have for us.

Otto Cate: Thank you very much for the presentation there. Before we jump into the Q&A, I'd like to share a couple of quick program notes with our listeners. If you'd like to see some information on future events or, of course, to review any of our sessions on demand, feel free to visit our main Support WebCast site there at support.microsoft.com/webcasts. There you will be able to view the on-demand streaming media for this particular presentation. We also plan to make a downloadable version of the slides available.

Of course, we'd also like to ask for any feedback on the events that we produce, subjects that you'd like to see in the future, the quality of events, that kind of thing. You can submit feedback by using our "Contact Us" page at support.microsoft.com/servicedesks/webcasts/feedback.asp. We'd certainly appreciate it.

With that, let's go ahead and jump into the Q&A session here. Feel free to ask any questions that you may have here for Jack and Dennis regarding the topic that we addressed today for you.

First question: Can this be done via scripting?

Jack: I'd like to address this one. Otto, that's a good question. I suppose it could be argued that really we should be able to take any of the steps that we are performing here and perform them through scripting. What I've decided to do really is to not include scripting in this particular presentation, because I was keeping this as an all Microsoft solution. I do know that there are some good scripting packages out there, some tools and utilities that can be used.

One of the things that we have seen with scripting is in an effort to try to chain the scripts. And I think that's what the question really revolves around, can we get the prerequisites and everything chained together in a script. There is some difficulty in determining when one MSI has completed and if it has been completed successfully, before allowing the scripting process to continue. So, as I say, our team has seen some difficulty in that area.

What this really would lead me into, though, is some very good news with regards to added functionality in the Windows Server 2003 environment and that is allowing WMI filtration to be used. So what I'm seeing in the future is perhaps allowing for these various MSI packages to be tested or have the prerequisites be established prior to allowing that particular MSI to be applied.

Now, again, you've heard me say before that I think simplicity is important. That process will be quite involved, and that's another reason that I elected not to go into great detail on it in this presentation.

My other thinking here is that the next product release will have a lot of this functionality built in. We may not have to go into something as complex, if we can get that product into the hands of a potential user before we have to go through that more elaborate process. Thank you, Otto.

Otto: It looks like that was actually the final question in the queue. So with that I'll go ahead and wrap up this session. I certainly wanted to thank Jack for coming out and giving us a great presentation. Of course, as always, we'd like to thank you, our listeners, for attending today's event. I certainly hope that this information proves helpful to you and your business, and look forward to seeing everyone again in the near future. Thanks, everyone, and have a great day.