I will explain a new error we will likely be seeing more of in the future with Windows 2003 Server and Active Directory. This is an error where the WebIT (OptiWebDataServer.exe) service will not start, even through the Service Control Panel, using what is believed to be an "Administrator" account. In this situation, most likely, the Service Control Panel will show that it tried to start the service, and the service did start, but then ended. Further, the Service Control Panel will probably say that the service started, but ended most likely cause it had no work to do. In this situation, there will be no WebIT logs, and no Security logs. Attempt to run the OptiWebDataServer.exe directly will work, showing no errors, which indicates that the service has everything it needs to run.
This error is most likely caused because the "Administrators" account being used does not have all the security rights (from above) it needs to run. And/or access to any and all files and directories and registry records on the server. This error appears to stem from 3 issues:
1) By default, it appears that Windows 2003 Server does not ship with the local "Administrators" group having all the privileges it needs to run services. In particular, the local security policies for "Create permenent shared object" and "Replace a process level token" do not seem to be set for the "Administrators" group with Windows 2003 Servers.
2) Another issue with Active Directory, is that the user with the true GOD account, will most likely create a policy for "Administrators" to also not have these two privileges, as they most likely will build this Administrators policy off the default setting for Windows 2003 to the Administrators group.
3) And a 3rd issue with this problem is that the user with the GOD account for the domain, will not be avilable and/or accessible to communicate with to verify the true settings of the policies for Administrators in the domain.
As result of these 3 things, even if one gets a local "Administrator" account, goes to the "Local Security Polciy" editor and manually adds in all privileges WebIT needs, the machine will not activate them (even after a reboot), as the policy for the domain will override any local policy, and not show you the true settings necessarily. Only the user with the GOD account with access to the policies for the Active Directory will be able to do this.
KB2005.0502
Problem: CGI programs are installed but not responding on Windows 2003 Server using IIS
This article applies to all CGI applications.
Last updated: 4/13/06
Problem
The CGI program is installed on Windows Server 2003, but the CGI application doesn't appear to be responding even though IIS is running.
Details
CGI applications require that CGI scripting be properly enabled on the web server. Versions of IIS starting with 6.0 on Windows Server 2003 have new restrictions on applications that require additional configuration steps to enable CGI programs. By default, any new CGI program must have an Application Extension Mapping defined for its executable in the website properties, AND it must be added to the Web Service Extension Restriction List (WSERL) before it will be executed by IIS.
Solution
First, be sure you have followed the basic installation instructions for the application correctly (copied the CGI executable file to your scripts folder and given it proper NTFS access permissions and the correct IIS execute permissions to run as a script).
Next, you will need to create an Application Extension Mapping for the CGI program executable in your website properties. To do this, open IIS Manager and view the Properties for your website. Click the the Home Directory tab and click the Configuration button in the Application Settings section to bring up the Application Configuration dialog. Click the Add button to add the complete local path to the CGI program executable file. Use Browse to locate it if necessary. Note: You cannot use a virtual directory in your path, it must be an actual path (i.e. C:\Inetpub\scripts). Be sure the Allow all verbs radio button is selected and apply your changes.
Finally, you must add the CGI program executable to the Web Service Extension Restriction list (WSERL). You can do this in one of two ways:
· Use the Web Service Extension section of the IIS Manager MMC to allow all CGI programs to run, regardless of whether they are entered in the WSERL. Note this option is easier to implement but somewhat less secure than the other method.
1. Open the IIS Manager MMC applet
2. Choose the Web Service Extensions section and set the "Allow All Unknown CGI Extensions" option to "Allow."
· Use the IIS IisExt.vb command-line script to add the executable to the WSERL.
1. Open a Command Promt window and change to the Sysvol\System32 folder (the default is Windows\System32)
2. Type the following:
iisext /EnFile ScriptPath\ExecutableName
where ScriptPath is the complete path to your Scripts folder, i.e. c:\Inetpub\scripts and ExecutableName is the filename of the executable, i.e. dompass.exe Thus, in our example, the complete line for enabling dompass.exe would be:
iisext /EnFile c:\Inetpub\scripts\dompass.exe
You should receive the following response:
Connecting to server …Done.
Enabling extension file complete
