IEAK Automatic Configuration

Modern OSs have evolved to a level of complexity that can be difficult to manage, and administrators often have to evaluate infrastructure changes on a case-by-case basis. Unfortunately, administrators have to weigh logical changes against the cost of implementing those changes. Although changing one tiny setting on everyone's desktop might simplify day-to-day administration, the size of your organization and the work piling up on your desk might not leave enough resources to make that tiny change. A little-known feature in Microsoft Internet Explorer (IE) called Automatic Configuration can help solve this problem and lower total cost of ownership (TCO). This feature lets you use a few mouse clicks and keystrokes on one machine to change application settings on thousands of desktops in your organization.

The History of Automatic Configuration Files
If you've been working with Windows since Windows 3.1, you probably remember that .ini files are the early version of Windows NT's Registry—the heart and soul of the Windows OS. These .ini files store all the necessary settings for Windows and its applications, and you can use Notepad or Edit to edit each .ini text file. The primary advantage of .ini files is that they're easy to work with, repair, and back up.

Automatic Configuration files are a new twist on an old theme. An IE Automatic Configuration file acts like a networkwide .ini file for all your IE installations. Thus, you can make configuration changes to all your browsers by simply editing one file on your network. If you think this feature sounds too good to be true, you're not alone. I thought the ability to change thousands of browsers by editing one file using a simple text editor seemed a little too impressive to believe. With my skepticism in overdrive, I decided to find out whether this feature lives up to its promise.

Starting with IEAK
To take advantage of Automatic Configuration files, you use the IE Administration Kit (IEAK) to deploy a custom browser throughout your enterprise. In "Deploying IE with IEAK," April 1999, I walk you through this process. However, that article references IEAK 4.x, and I use IEAK 5.0 for the discussion and examples in this article. (You can download IEAK 5.0 from Microsoft's Web site at http://ieak.microsoft.com. Be aware that Microsoft requires you to register for a distribution code before you can start working with IEAK.)

When you use IEAK to build a custom IE deployment, you have the option to preprogram IE to look for an Automatic Configuration file, and you can tell IEAK where to look. This file location must be a URL, so you'll need to put your Automatic Configuration file on a Web server in your organization. For example, on a Microsoft Internet Information Server (IIS) known as ARCHITECT4, I created a subdirectory called autoconf. I might eventually have different versions of IE in my organization, so I named the Automatic Configuration file ie5.ins. Putting this information together yields a URL of http://architect4/autoconf/ie5.ins, which I entered into the IEAK Auto-config URL dialog box, which Screen 1 shows. For test purposes, I set the system to automatically configure every 15 minutes so I can quickly test changes to the Automatic Configuration file. In an enterprise environment, you'll need a much larger value in the Automatically configure every text box, or you can leave this field blank. If you don't enter a value, IE processes its Automatic Configuration file every time users start their browser. When you deploy a browser with an IEAK-based build, you can verify that you selected the Automatic Configuration option by checking the Internet settings, which Screen 2 shows. To do so, select Internet Options from IE 5.0's Tools menu, and click LAN settings on the Connections tab.

Creating an .ins File
Now that you know where to send IE for the .ins file, you might be wondering where the .ins file comes from. You can manually create an .ins file, but you don't need to because IEAK creates one when it builds a customized IE deployment. For my example, I used IEAK to create an IE build that users can download from my Web server. During the building process, IEAK put the build files in the directory that I specified in the Automatic Configuration dialog box.

One of these build files is install.ins, which contains all the settings for the customized IE deployment that I specified in IEAK. (Figure 1 shows an example file.) The IE setup process uses this file to configure optional settings, which is how ISPs can deploy customized browsers that display their logos, title bars, and favorites lists. I'm working with a 32-bit English version of IE, so IEAK put install.ins in a subdirectory called ins\win32\en\ off the root of my build directory. When I publish this file on my Web server, I'll rename it ie5.ins. As you can see from Figure 1, this file has section headings, attributes, and values just like an .ini file.

You're finished! All you need to do to use Automatic Configuration is build an .ins file, put it on a Web server in your organization, and point all your browsers to it. However, I prefer to edit the .ins file down to a core set of options, such as proxy settings, title bars, and favorites. This process ensures that IE changes only the settings that I want to maintain and reduces the bandwidth that these changes consume on the network. Keep a copy of your original .ins file in the same directory in case you need to refer back to it.

Securing Files
The ease with which you can change Automatic Configuration files creates the risk of accidentally messing up all your browsers. For example, a typo in your Automatic Configuration file can be a nuisance, or it can interfere with the functionality of users' browsers. In addition, imagine the havoc an intruder can wreak on your system by using your Automatic Configuration file—potentially forcing you to manually reconfigure each desktop copy of IE. Therefore, take extra precautions when you secure your Automatic Configuration files. Consider setting the file as read-only for the Everyone group. By making the file read-only for everyone in your organization, you can be sure that no one accidentally changes the file. (Give yourself read-write access whenever you need to change the file.) In addition, extra-tight security will remind you that you shouldn't change your Automatic Configuration file often.

Changing .ins Files
So you've put together your .ins file, and you're using it to manage the browsers on your corporate desktops, but you discover that you want to control IE options that you didn't include in your .ins file. In this case, or if you're having syntax problems with your .ins file, IEAK contains documentation that can help. You can find this information in an Excel spreadsheet called insref.xls in the toolkit subdirectory of the IEAK directory.

Automatically Administer Everything
Creative administrators have many options, such as logon scripts and Registry utilities, to accomplish some of the same application-management feats that they can achieve using an Automatic Configuration file. But why go through the hassle when Automatic Configuration is an easy-to-use solution? This little-known feature introduces a revolutionary way to manage desktop settings in an enterprise environment, and I would love to see Microsoft and other software developers implement similar functionality in all their applications.

End of Article