Hi,

I was wondering if anyone has experienced any issues with a 2003 Server installation of Xoops?

I installed XOOPS on my web host site. It's a Linux-based account, and everything has been running smoothly.

I decided I wanted to try it out on my Laptop, which is running 2003 Server.

I initially tried it with IIS and the following:

php-5.0.4
mysql-4.1.10a-win32
Xoops-2.0.10RC & xoops-2.0.9.2

It installs fine, but when selecting various admin menus eg adding a poll in the poll module, or creating a news topic, the browser just sits there and doesn't do anything.

In the case of adding a new News Topic, this is the link:
http://localhost/xoops/modules/news/admin/index.php?op=topicsmanager - It just sits there no matter what link you click (add, edit, list polls) - in this case it's using the index.php file with a query string, so I'm wondering if there might be a setting that needs changed somewhere to allow it to work...

Anyway, I then tried Apache (apache_2.0.53) - got it set up correctly (disabled IIS of course!) and the same thing occurs - this to me shows it's a 2003 Server issue and not an IIS one.


Following this, I tried it on XP as I have the luxury of dual-booting and it works well with no issues.

Could this be a permissions issue with 2003 Server?


I'm new to XOOPS and not an experienced 2003 Server user...

Any help would be excellent!!! (I'm satisfied with XP, but I just want to know why I can't get 2003 Server working!)



(NOTE - I use Firefox, but the same pattern was observed with IE6 too)

I've been using XOOPS with a Windows 2003 server and IIS 6 for over a year without any issues. Have you set the NTFS permissions for the IUSR_ correctly? Is there any specific reason for using PHP5 over PHP4 (not all PHP5 bugs have been squashed out in XOOPS yet)? Do you have the PHP application mapping in IIS configured to use ISAPI or CGI?

Thanks for your reply, Brash.


My permissions seem to be fine, but that could be the problem...

When I look at the security tab, there are no greyed out boxes, and all permissions are allowed for all the users.

I assumed that if there was a permissions issue that XOOPS might have complained either during install, or when I try to access the modules. I'll double check the IUSR_ - although I know it's there for some of them.

I was wondering if it was something to do with 2003 Server handling url queries differently...or some setting - Just clutching at straws though.


I chose PHP5 because it was the newest, no other reason other than that I didn't want to have to set it up again in the future if there were things that later relied on new features of PHP5. It works well in XP though, so we can illiminate PHP5 from this (unless of course there's a 2003 Server specific PHP5 bug).


As far as I can remember (it's been a while since I set it up and I just forgot about it after I did it) PHP is set up as an ISAPI - am I right in thinking that that's the best solution (I'm sure each has it's benefits)?

If the IUSR_ account is not in the list when you look at the security tab, then it does not have explicit permissions to your XOOPS site (although it might have indirect access via group membership). Also remember that the IUSR_ account will need modify permissions to the cache, uploads and template_c directories, as well as any other upload directories specific modules might need.

Windows XP / IIS 5.1 and Windows 2003 / IIS 6 are very different beasts. Probably the biggest single difference with IIS 6 is that out of the box all web extensions are disabled. You must go into the web extension panel and setup a web extension for your PHP application mapping and set it to allow. Either that or just set the existing "allow all unknown ISAPI extensions" to allow. It is less secure, but in your case I don't think that is an issue.

For IIS, ISAPI is both more secure and much more effcient that CGI. In a nutshell, CGI is an executable, and for your IUSR_ to be able to execute it you must loosen the permissions in IIS. ISAPI does not require this as it is a DLL. CGI is also very ineffcient in it's memory usage. CGI is loaded into and out of memory for every single request, ISAPI on the other hand is loaded into memory once and that one instance is used to serve all requests. This makes ISAPI MUCH more efficient, and performance wise ISAPI is WAY ahead of a straight CGI configuration. Fast CGI is another story, but it is more or less half way between ISAPI and CGI, so it's a bit different.

Almost forgot. Can you;

1) Enable PHP debug in XOOPS on your Windows 2003 install?

2) Can you post the last few lines of your IIS logs when XOOPS goes into this stalled mode?