How-To: Installing BugZilla on Windows Server 2003 and IIS

Update, Oct. 13, 2010: I have just added a post on updating BugZilla to v3.6.2 from the below-mentioned version.

Recently, I found myself in need of a bug-tracking solution. Never having used one, I decided to try the open-source BugZilla to get a feel for how these kinds of programs work and what the features are.

On Windows, BugZilla gives you the choice of running in the open-source Apache webserver, or Windows’ built-in webserver, IIS. I chose to set BugZilla up to use IIS because I am already running it for web development, and I wanted to keep things relatively simple.

After a near-all-nighter, and another day of hair-pulling frustration, I got BugZilla up and working on IIS. It was not fun. It occurred to me that, considering the difficulties I had, and the fact that the information that is available is spread out over the Internet, and much of the crucial information is not out there at all, it might be a service to the community to post what I found out.

NOTE: this information was accurate when I posted it, for my system; I take no responsibility for any issues you may experience, and I can’t guarantee these steps will work for you. They worked for me, though.

Downloading the required software

BugZilla has a page that will at least get you started installing BugZilla on Windows. For simplicity’s sake, from now on I will refer to this page as “the BZ IIS page“.

Start there, and follow their directions to download BugZilla itself: version 3.0.3 is the latest stable release at the time of this writing. They start with instructions for downloading BugZilla from CVS; I recommend that you don’t do this. Instead, scroll down to the instructions under the heading “Installing BugZilla From the TarBall“, and follow them. The instructions boil down to extracting the files into a directory; WinZip will handle the extraction (there is a free evaluation version available at that link) if you don’t already have a utility that handles TarBalls. The directions suggest that you create, and extract the files into, C:\Bugzilla; I second the recommendation. It makes it a lot easier to follow the directions if you do this. Note that, by default, when the TarBall is extracted, it will create a sub-directory under C:\Bugzilla with the version number. I strongly recommend that you move all the files and sub-directories under this sub-directory—on my system it was C:\Bugzilla\bugzilla-3.0.3—directly under the C:\Bugzilla directory. Again, it will make the later steps easier to follow.

Once that’s done, the BZ IIS page then directs you to download and install ActiveState Perl.
WARNING!! There is a HUGE “Gotcha” here! The directions state “Download the ActiveState Perl 5.8.1 or Higher. . .”. What they don’t tell you is that the latest version of ActiveState Perl available at the time of this writing — 5.10.x —  is NOT COMPATIBLE with BugZilla! To be specific, most of the Perl add-on modules required by BugZilla are not available for ActiveState Perl 5.10.x!! Don’t download v5.10.x!! Instead, download the previous version, 5.8.x. If you download the wrong version, you will not be able to install the required modules to get BugZilla working. You will simply be told that the modules you need were not found.

Go ahead and follow the instructions to install Perl, and to create the C:\Temp directory and set the permissions. To simplify things, I gave System, NETWORK_SERVICE, and IUSR_<machinename> write permission to this directory. Be sure to Log out, and Log back in, after installing Perl, because the PATH Environmental Variable was set by the Perl installation, and you need to Log out & back in to get the change picked up by Windows. We’ll need the variable set for the next step.

Install the Perl modules

Continuing with the directions from the BZ IIS page, we next need to install the modules. You can do this from the command line by opening a Command Prompt and typing, IIRC, “ppm.bat” (without the quotes). I used the module-installing GUI, which you open simply by typing “ppm”(without the quotes) at a command prompt. HOWEVER- there is another “Gotcha” here. Before attempting to install the modules, you need to add the BugZilla module repository to your installation! If you fail to do this, once again, Perl will be unable to find the modules you need. If you are using the GUI, add http://landfill.bugzilla.org/ppm as a Repository, with the name “Bugzilla”. If you use the command line, type: repo add Bugzilla http://landfill.bugzilla.org/ppm. Note: you may come across instructions indicating that you need to follow this by repeatedly typing a command that includes “rep up[…]”. THIS IS NOT NECESSARY in this version of Perl and will result in an error.
Follow the rest of the instructions for installing the modules.

Configure IIS

You do not need to download Apache, because we are using IIS instead. At this point, follow the provided link for instructions on configuring IIS for BugZilla: do everything listed in 2.2.4.2, and note that there is no space between the “-x” and the path to BugZilla in the script mappings. Do all the optional steps except the Microsoft Knowledge Base steps. At that point, stop and go no further. DO NOT go on to 2.2.5 and try to start BugZilla; it won’t work yet.

Instead, you need to do a few other things: open up the IIS manager: type this into START->RUN:
%SystemRoot%\system32\inetsrviis.msc –this will open the IIS Manager. In the left pane, click the + sign to expand your server, then click “Web Service Extensions”. If you don’t see the “Allow”, “Prohibit” and “Properties” buttons, click the “Extended” tab at the bottom.
You will need to Allow “All unknown CGI Extensions”, in spite of the warning it gives you;  BugZilla just won’t run without this setting.

Next, make sure all of the following are listed, and are Allowed: Perl CGI Extension, Perl ISAPI Extension, Perl Scripts, PerlEx ISAPI Extension.
If you need to Add any of them, click on the hyperlink “Add a new Web service extension…” on the left of the pane. The “Extension Name” is simply the name as noted above: “Perl CGI Extension”, or “Perl ISAPI Extension”, or…etc. You then select, or browse to, the
proper .EXE or .DLL file. For “Perl CGI Extension” you need to add some parameters; you’ll enter C:\Perl\bin\perl.exe “%s” %s . For
“Perl ISAPI Extension” you’ll enter or browse to C:\Perl\bin\perlis.dll; and for “Perl scripts”, it’s simply C:\Perl\bin\perl.exe.
Finally, for PerlEx ISAPI Extension, it’s c:\Perl\bin\PerlEx30.dll. NOTE: all of the above assumes you have installed Perl to the default of C:\Perl.
If not, you’ll need to adjust the paths. Also, the name of the PerlEx30.dll may be different if you have a later version of Perl than mine.

Configure BugZilla

Go back to the BZ IIS page and pick up after all the steps for configuring Apache. You should be at the heading “Configure BugZilla”. Note that the command you need to run starts with “perl“: you should type perl checksetup.pl after changing to the Bugzilla directory (which should be “C:\Bugzilla”, or ”
C:\Bugzilla\bugzilla-3.0.3″, if you followed recommendations). If you are told that you need to install more modules, go ahead and follow the instructions, remembering that you can scroll the command-line window up to see the text that has scrolled off the screen.

Once checksetup.pl has run without telling you there are required modules missing, you should see the text that tells you that localconfig was created. Localconfig does not exist until it is created by checksetup.pl; and checksetup.pl won’t create the file until checksetup.pl runs without finding any missing modules.
Localconfig is a text file in the Bugzilla directory that contains various settings; the one we’re concerned with right now is the password for the MySQL database. Follow the instructions to enter the password in the localconfig file. WARNING! VERY IMPORTANT: if you use Notepad as your editor, when you Save the file, change the file type from “Text documents(.TXT)” to “All files(*.*)” and make sure the Encoding is “ANSI”. This tripped me up for hours and caused a CGI error in the web browser! If you use another editor, be careful when saving! Once you’ve edited and saved the localconfig file, run perl checksetup.pl from a command prompt again.

At this point, you will likely get an error stating you could not connect to the MySQL database. For some reason, this seems to occur even if you have correctly entered the password in localconfig. To fix this, you need to reset the password. Open a command prompt window and log in to the MySQL database as root; there is a picture of the required commands at the top of the BZ IIS page; of course you will need to enter the password you used when first setting up MySQL, rather than the one shown in the picture. Once you are logged into MySQL, enter the following command, replacing ‘sockmonkey’ with the password you set when you set up the bugs account in MySQL: set password for ‘bugs’@’localhost’ = OLD_PASSWORD(‘sockmonkey’); [enter the single quotes, exactly as shown].

Now, run checksetup.pl again from a command prompt using the same command: perl checksetup.pl

This time, it should create the tables for you, exactly as shown in the first set of instructions. Once that finishes, it’s worth checking your server configuration: open a command prompt window and enter: perl testserver.pl http://localhost/Bugzilla — assuming your IIS virtual directory was named “Bugzilla”. If not, change the command accordingly. The test should run successfully; at this point, you can go back to the BZ IIS page and take care of entering the parameters and setting up the scheduled tasks. In order to enter the parameters, you will need to run BugZilla in a browser. Open up your web browser, on the same computer on which you installed BugZilla. Assuming your IIS virtual Directory was “Bugzilla”, you would type the following into your browser:
http://localhost/Bugzilla.
“Gotcha” – if you get a “HTTP 400 – Bad Request” error message at this point, you probably have not set up your loopback adapter. Go to this page at the Microsoft Knowledge Base: http://support.microsoft.com/kb/842693 and follow the instructions under the following section:

Windows Small Business Server, Premium Edition

To resolve this problem, set the loopback IP address for the default Web site in IIS[…]

Once you’ve done that, the error will go way. Finish up the instructions on the BZ IIS page, then come back here for the final step.

Final step- Run BugZilla – Error??

You should now be able to connect to BugZilla.

But — you may see an Error, right at the top of the page! If you do, and it starts with “Use of uninitialized value in substitution (s///) at (eval[…]“, it is caused by a bug in the 3.12 version of Perl’s CGI.PM module. It’s fixed in the 3.33 version, which is at
http://search.cpan.org/src/LDS/CGI.pm-3.33/; you can try downloading the entire directory structure and following the directions
in the README file, but what worked for me was to copy the CGI.pm file over the previous version in my C:Perllib directory.
Simply download the file to the C:Perllib directory and say “Yes” when Windows asks if you want to overwrite the existing file.

That’s all, folks!

Yes, I really did go through all the steps and errors noted above, and found the workarounds mentioned. My apologies if I failed to credit the first person to locate a given fix, but frankly, I didn’t keep track of it as I went, as I was trying everything I could think of and seeing what worked.

It’s sad, but this is typical of the installation process for an open-source application. In fact, this was easier than some, as many require you to download the source code and compile it yourself! And some even require you to use a source-control app like CVS to get the source code! I’m a developer, with 15+ years of experience as a Computer Consultant on top of it, and look at the trouble *I* had! I can’t even imagine what misery the typical end-user would have gone through trying to install an app like this…you could respond that this is an app aimed at developers, but the fact is, I’ve seen this over and over in hundreds of open-source apps, intended for end-users as well as developers.

In my search for help on this installation, I saw a lot of glib responses along the lines of “that’s why you shouldn’t use IIS!  Use Apache[an open-source web server] on Linux!” This is a poor attitude. We’re told that the app runs on IIS; if so, it should just RUN– or tell us it doesn’t! This kind of sarcastic, Linux/Open-source-fanboy response doesn’t help. And it ignores the fact that many users either have their web server choice dictated by management, or just simply don’t have the time or desire to get yet another PC, running yet another web server, running. Open-source apps like this are just not going to get wide acceptance until they do something about their installations. This situation is something like the experience installing apps 15 years ago on DOS/Windows 3.1- miserable. I recall all sorts of issues with missing runtimes, “DLL Hell”, etc. But Microsoft did fix it, for the most part. There is a long-time standard for installing apps under 32-bit Windows, which almost every closed-source app uses – Windows Installer [most developers use third-party, or Visual Studio’s built-in, tools that create Windows Installer .MSI files, rather than using Windows Installer directly]. In fact, ActiveState Perl itself uses Windows Installer , and it makes installing their product much easier. There are free and open-source install makers, many of which can create .MSI files, as well. Most of these tools are capable of creating installers that install all required libraries and other apps, using Merge Modules or similar functionality.

There just is no excuse for this kind of amateur-hour installation process; it doesn’t serve these apps well (no pun intended). I’s a shame that these apps don’t have modern installers, because they have a lot to offer; but most users are just not going to suffer through these kinds of drawn-out, poorly documented installations. Just look at the amount of information I had to compile here!

OK, I’ll get off my soapbox now. I’m still looking forward to trying BugZilla out. Perhaps I’ll post my impressions later…

Troubleshooting

I’m sorry to say I don’t have the time to help much if you post questions. All I can say is, if you follow the instructions above, in the exact order I posted them, you shouldn’t have trouble. Especially pay attention to setting permissions on the various directories; make sure whichever user your IIS is running under has access to all the Perl folders. I also need to note that later versions may have fixed some of the above issues…or created others. I can only say that what I wrote above is an accurate representation of what I went through.

Advertisements
  1. #1 by Loriann Sadik on March 22, 2017 - 6:23 am

    I used to be suggested this web site via my cousin. I am no longer sure whether this put up is written through him as nobody else recognize such specific about my problem. You are amazing! Thanks!|

  2. #2 by GD on January 3, 2012 - 2:17 am

    Help me to add the testopia extension to the bugzilla.

  3. #3 by GD on January 3, 2012 - 2:14 am

    Please help me to add the testopia extension to the bugzilla 3.4.2

  4. #4 by biju on February 10, 2011 - 8:10 am

    i had put a post earlier…now i got that working..i reinstalled template-toolkit package..
    checksetup.pl executes without any issues …but now when i try to access bugzilla like
    http://localhost/bugzilla/index.cgi i get the following errors

    ============
    Undefined subroutine &Params::Validate::SCALAR called at C:/Perl/site/lib/DateTime/Locale.pm line 41.
    BEGIN failed–compilation aborted at C:/Perl/site/lib/DateTime/Locale.pm line 143.
    Compilation failed in require at C:/Perl/site/lib/DateTime.pm line 45.
    BEGIN failed–compilation aborted at C:/Perl/site/lib/DateTime.pm line 45.
    Compilation failed in require at Bugzilla/Util.pm line 53.
    BEGIN failed–compilation aborted at Bugzilla/Util.pm line 53.
    Compilation failed in require at Bugzilla/Error.pm line 33.
    BEGIN failed–compilation aborted at Bugzilla/Error.pm line 33.
    Compilation failed in require at Bugzilla/Install/Filesystem.pm line 31.
    BEGIN failed–compilation aborted at Bugzilla/Install/Filesystem.pm line 31.
    Compilation failed in require at Bugzilla/Config.pm line 38.
    BEGIN failed–compilation aborted at Bugzilla/Config.pm line 38.
    Compilation failed in require at Bugzilla.pm line 38.
    BEGIN failed–compilation aborted at Bugzilla.pm line 38.
    Compilation failed in require at C:\Bugzilla\Bugzilla-3.6.4\index.cgi line 34.
    BEGIN failed–compilation aborted at C:\Bugzilla\Bugzilla-3.6.4\index.cgi line 34.
    For help, please send mail to this site’s webmaster, giving this error message and the time and date of the error.

    =============
    not getting why its happening..aAny guidance will be of great help
    thanks
    biju

    • #5 by andrewcushen on February 10, 2011 - 10:57 am

      Biju-

      Have you tried un-installing/re-installing the Date/Time package? Generally, you can count on the error messages to point in the general direction of the actual problem. Here, the messages are pointing you to the Date/Time package.

      If the un-install/re-install process doesn’t help, make sure there are no prerequisites you are missing for Date/Time. Also, sometimes a specific version of a package is required, and you may need to uninstall the package if it’s a newer version than is required, then find the older version.

      Good luck.

      • #6 by biju on February 13, 2011 - 11:18 pm

        HI andrewcushen,
        sorry for the late reply ,
        thanks a lot for getting back on this ..
        when i execute “checksetup.pl” the following are the entries related to datetime and timedate

        Checking for Digest-SHA (any) ok: found v5.48
        Checking for TimeDate (v2.21) ok: found v2.24
        Checking for DateTime (v0.28) ok: found v0.53

        Is the version change[v0.28 –>0.53] a problem here? a tried reinstalling the datetime package…still the problem persists
        Also the message given by “checksetup.pl” shows the following at the end

        ——-
        Precompiling templates…done.

        Now that you have installed Bugzilla, you should visit the ‘Parameters’
        page (linked in the footer of the Administrator account) to ensure it
        is set up as you wish – this includes setting the ‘urlbase’ option to
        the correct URL.

        is the error i am getting related to this?.
        I m very new to bugzilla/perl so not able to get why this error is coming..any guidance will be of great help.

        biju

        • #7 by biju on February 14, 2011 - 1:06 am

          Hi andrewcushen,

          i solved that issue…actually problem was with “Params::ValidatePP.pm” file ..i downloaded and rechecked then it started working 🙂
          thanks for taking time to reply my query
          biju

  5. #8 by biju on February 10, 2011 - 6:03 am

    hi ,
    i followed all the steps as told…but while executing “checksetup.pl” at the end of it i get the following message

    =============================
    Reading ./localconfig…

    OPTIONAL NOTE: If you want to be able to use the ‘difference between two
    patches’ feature of Bugzilla (which requires the PatchReader Perl module
    as well), you should install patchutils from:

    http://cyberelk.net/tim/patchutils/

    Checking for DBD-mysql (v4.00) ok: found v4.018

    Precompiling templates…Template creation failed: failed to create constants na
    mespace: failed to load Template/Stash/XS.pm: Couldn’t load Template::Stash::XS
    2.22:

    Can’t load ‘C:/Perl/site/lib/auto/Template/Stash/XS/XS.dll’ for module Template:
    :Stash::XS: load_file:The specified module could not be found at C:/Perl/lib/Dyn
    aLoader.pm line 226.
    at C:/Perl/site/lib/Template/Stash/XS.pm line 31

    BEGIN failed–compilation aborted at C:/Perl/site/lib/Template/Stash/XS.pm line
    31.
    Compilation failed in require at C:/Perl/site/lib/Template/Config.pm line 82.
    ================================
    i dont know why this is happening as the xs.dll is already there in the said path..
    Any guidance will be of great help
    thanks
    biju

  6. #9 by andrewcushen on October 22, 2010 - 12:19 pm

    Sounds like a permissions issue. Are you sure you’re signing into BugZilla with an Administrative account?

    Make sure you have set up the ACLs – the Windows permissions – on the BugZilla directory! You have to allow the Windows user you are logged in as read/write or full permissions. I bet that’s the problem.

    That is, you need to set the permissions in Windows Explorer to allow the account BugZilla is running under–usually starts with IUSR_–to have full control of the folder BugZilla lives in. The actual folder in Windows Explorer, not the virtual folder in IIS.

    • #10 by tolga ciftci on October 22, 2010 - 1:15 pm

      Once again you were right.

      All I need to do is:

      Go to c:Bugzilla
      Right Click on the folder
      Properties
      Security Tab
      Select the group which you want to give access permissions to.

      Once again thank you so much for your help.

    • #12 by tolga ciftci on October 22, 2010 - 2:29 pm

      I am hoping to bother you one last time :)) We used to use bugzilla 2.22.1 on a different machine and since I moved to the server with a stand alone installation is there a way to export bugs from 2.22.1 to 3.6.2 on the new machine?

      Thank you,
      Tolga

      • #13 by andrewcushen on October 22, 2010 - 2:57 pm

        I’d think so, but now you’re getting out of my area of expertise.
        I’d think you would have to use a mySQL command on the old server to export the data from the tables in the old mySQL database, then copy that data over to the new server, and use a command to import it.
        You’d have to check the mySQL documentation at http://dev.mysql.com/doc/, or see if they have a support forum.
        Be sure you check the docs carefully to make certain you won’t be overwriting the data in the database on the new server; you want to import the data into the existing tables, not wipe them out.

        Obviously, if you used a different database than mySQL, you will have to check its docs.

  7. #14 by andrewcushen on October 22, 2010 - 11:36 am

    Tolga-

    Have you tried using editparams.cgi? Put that at the end of your BugZilla URL, like this:
    http://myServerNameOrIP/BugZilla/editparams.cgi
    Obviously you will need to change the URL to reflect the name of your server.

    Make sure you are logged in to BugZilla with Admin rights.

    It may also be worth running Perl checksetup.pl from the command line again.

    • #15 by tolga ciftci on October 22, 2010 - 11:39 am

      That is when I get the error. I go to edit params on Bugzilla and change the smtpserver name and get an error 😦 Frustrating@!@#

  8. #17 by Andrew on March 12, 2010 - 4:40 am

    You are welcome. Glad to help; I always find it so frustrating when I Google and Google and nothing comes up!

    • #18 by tolga ciftci on October 21, 2010 - 2:41 pm

      Thanks for the prompt reply. I am using perl 5.8.9.827. Should I go head and upgrade it to 5.10.x?

      I added the repo by using the GUI Perl Package Manager>Preferences>Repositories tab and add.

      I also tried the command line as well.

      I will double check the instructions on creating the bugs user I might have missed something. I believe all I did was to go to logconfig and change the password I don’t recall creating the db.

      • #19 by andrewcushen on October 21, 2010 - 4:30 pm

        Yes, you should upgrade ActivePerl to the latest stable version. As I think I noted in my post, there are several bugs in the earlier version that will prevent BugZilla from running. I believe I may also have had issues trying to add the repository under the earlier version of Perl, as you did.

        Take another look at the BugZilla docs; there is a specific command you need to run that will create the Bugs database in mySql, and one for creating the user. If you can’t find it, let me know and I will look for it if I have time later.

        Make sure you follow the link in the post above about upgrading ActivePerl, particularly making sure you stop IIS first.

    • #20 by tolga ciftci on October 21, 2010 - 4:59 pm

      I want to thank you so much. I got it up and running all I need to do is upgrade perl and will do that tomorrow, I have one question not bugzilla relater or kind a.

      Now I can access bugzilla with :port number. How do I set it so that we can also access it from out side the LAN? like under http://www.companyweb/bugzilla?

      Nothing urgent, if you can help me with that when you get a change I will appreciate it.

      Thank you,

      • #21 by andrewcushen on October 21, 2010 - 5:35 pm

        I’m glad you got it working.

        As far as accessing it from outside the LAN, that’s a bit more involved, depending on your specific set-up. First I would note that you need to be very sure you have your security set up properly before doing this. Make sure you have set up BugZilla to require a username/password for access, make sure you have set up ACLs on the files in the BugZilla directory, etc. I would be leery of opening the server to the outside world if there is anything other than BugZilla running on it, because the configuration you need to do to get BugZilla running—removing restrictions on all CGI applications, etc.—can cause security vulnerabilities. You may think you have nothing of value to an attacker on your server, but that doesn’t matter; I recently helped a client secure a server that had been hacked, where the hacker set up a high-speed e-mail server on it and was sending out hundreds of Spam e-mails per second and the company couldn’t send their own legitimate e-mail out because they were on a Spam blacklist. Also, your competitors might be interested in your client list or your source code, or even a list of unfixed bugs, which could help them crack installations of your software in the wild. Remember, there are tens of thousands, at least, of people out there who have port scanners running on entire ranges of IP addresses, just looking for servers that are not properly secured. If your admins are not very good at securing servers, I would recommend the approach I use: set up a VPN, and have outside users connect to your internal LAN over the VPN. It is fairly easy to set up a VPN on a Windows 2003 server; you just need a second network card in the server, and they’re very cheap these days.

        That aside, the first step to what you want to do is to set up the BugZilla server so you can access it on the LAN without a Port number. This involves setting up, in the IIS Manager, the BugZilla virtual directory directly under the Default Website, and setting up the Default Website itself to run on Port 80.
        Next, you would need to have your Domain name (mycompany.com) set up to point to your internal webserver, if it is not already. Alternately, if your domain/main website is set up with a hosting comany, you should be able to get them to set up a sub-domain to point to your internal webserver, which would look something like http://www.BugZilla.mycompany.com, and would likely be a better approach.
        You would then need to open Port 80 in your router/firewall and point it at your internal webserver.

        It’s difficult to be more specific without knowing more about your existing setup: is your company’s public-facing website currently with an external hosting company, or is it hosted on your internal LAN? If it’s on your internal LAN, is the BugZilla server also the main webserver?
        If you’re with a hosting company, their Tech Support/Customer Service reps should be able to help you set this up.

        • #22 by tolga ciftci on October 22, 2010 - 11:24 am

          Thank you for all your suggestions. I feel like I am bothering you but I just can’t find answers out on the web. I entered the SMTP information wrong while installing and now when I go to Parameters and change the SMTP I am getting an error:

          Can’t rename data\params.HKGFG to ./data/params: Permission denied at Bugzilla/Config.pm line 301.
          For help, please send mail to this site’s webmaster, giving this error message and the time and date of the error.

          [Fri Oct 22 11:20:59 2010] editparams.cgi: Can’t rename data\params.HKGFG to ./data/params: Permission denied at Bugzilla/Config.pm line 301.

          Do you know how can I change it from the command promt using perl again? Since bugzilla doesn’t like it.

          Thank you,
          Tolga

        • #23 by tolga ciftci on October 22, 2010 - 11:57 am

          UPDATE on the issue: I just figure that Bugzilla doen not let me change any parameters at all!!! Hmmmm

          Hope my problems will also help others

  9. #24 by Jamie on May 5, 2009 - 3:02 pm

    I cannot thank you enough for this post! I was tasked with installing Bugzilla on a Windows Server running IIS. I too was pulling my hair out until finding your post.Also, I agree fully with your comments on open-source projects and their installation.Excellent work. Thank You!

  1. DotNetNuke
  2. How-to: upgrading BugZilla on Windows Server 2003 and IIS « Andrew Cushen's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: