Server 2008 R2 - Service Pack 1 problem

Hi all,

I have an outsytems development server with Windows Server 2008 R2 and after installing the new Service Pack 1 I couldn't access my espaces anymore as it showed up an error 500 - Internal Server Error. I checked the services and logs and everything looked fine.

I'm not an expert about installing outsystems nor configuring the platform, but nonethess if anyone else had this problem and knows a solution I'd appreciate the help.

Thanks in advance for the help.

Luis Fernandes
Hey, count me as a SECOND user with this problem! I intalled SP1 on my development machine (Windows 7) a few days ago, just tried to get to my local eSpaces and they are doing the same thing. No errors going to Event Log in Windows or the OSAP log either. :(

I tried re-publishing, that did not solve the problem either.

Can't you access any eSpace or just some of them?
Do you eel this simptoms when browsing to your Applications or using Service Studio?
I have benn able to successfuly install the SP1 on a windows 2008 R2 and all my applications look good.

With best regards,
Renato Gonçalves
Renato -

I can't get to any of my eSpaces on the system, but Service Center comes up fine. The error page mentions difficulty reading web.config. I have attached a screenshot for you.

Hi Justin,

That looks like a serious problem.

Could you e-mail our support team's address - - with these details, so they can reply directly to your e-mail and help you troubleshoot this faster?

When anyone finds a solution for this, please let us know. Is this only happening for OutSystems apps?


Paulo Tavares
Hi again,

In my case the problem was on the ISAPI module.

I couldn't open any eSpace nor the servicecenter. However service studio connected fine to the server and I honestly can't remember if i was able to publish anything.

As the service pack is uninstalable I'm gonna reinstall it so I can post a screen too

Luis Fernandes
Paulo -

Just sent it, thanks!


Here's what i tried so far:
  • i was able to install sp1 on a more recent outsystems server with no problems
  • when i installed (again) sp1 on the older server where i had problems i saw again the error message attached
So i compared a bit the configurations on the two servers to try to figure out what was different that could have to do with the problem. On the IIS7.5 part, all the configs i could check were the same. I noticed that the platform versions were not the same on both servers, the newer has version and the older has version Also, another difference is that the new server has the community edition licence and the older server has the basic edition licence. I also found out that the newer server has sql server 2005 (the installed by default) and that the older server has sql server 2008 (don't remember if it is express edition or not...)

If you need me to check anything else just ask!

Thanks in advance,
Luis Fernandes
I just upgraded to using the Community Edition installer and my problem was *not* resolved.

Hi Luis and Justin,

Thanks a lot for your feedback. This will surely help us track down the problem.


Paulo Tavares

Could you please check if you have the "Request Filtering" feature available in the IIS Manager, when selecting "Default Web Site" ?

João Portela
Joao -

Yes, it is available on the machine that giving me problems. I have *not* installed SP1 on my other servers yet, I am holding off until I know for sure that this works. I might be tempted to do a snapshot of the VMs and install it and see if it works, though.


Yesterday I've installed Windows 7 SP1 on my machine to try to replicate your problem. I think I got the same problem as you: accesses to the default directory (http://<server>/<application>/) was not working but accessing directly to a page (http://<server>/<application>/Page.aspx) was working. Alos the Service Center installtion was succesful.

One of the things I notice in the IIS Manager was the lack of some items, for instance the "Request Filtering" one.

I search for similar problem in the internet, and although I found similar problems, answers posted did not resolve the problem.

I gave a look into IIS logs (
c:\Windows\iis7.log) and I notice that during SP1 installation there were some IIS module unistalled and installed, and some of them were not succesful installed. I advise you to look into IIS logs (c:\Windows\iis7.log) to found out if you got the same problems as I did.
I've tried to install manullay the moduled that did not installed during the SP1 upgrade, but no success :(.

My last resource was a little drastic, I've unistalled IIS and installed it again. the result was: everithing is woking again :D.

I'll pass this information to OutSystems Support team so they can find out the exact problem and a pratical solution.

João Portela

Hi guys,

Before you try to unistall IIS, and install it again, I would suggest you to try to re-install some of the IIS features. By just re-installing some of the features you may be able to fix the problem.

João Portela
Hi guy's I've been having the same problem.
Even after deïnstalling SP1 I had problems getting the community edition back to work.
BUT! there is hope, I found this post

I executed the command start /w pkgmgr /uu:IIS-WebServerRole;WAS-WindowsActivationService;WAS-ProcessModel
after that I was able to reïnstall the community edition again.
Wow Louis - great find. Thanks a lot for sharing!

I'm looking forward to hearing back from the rest of the guys who have this problem.

By the way Louis - we're testing out a community meetup in the Netherlands. This pilot session will be on April the 14th - I hope you can make it :)


Paulo Tavares
Louis -

Thanks! That fixed it for me as well!

That being said... when Agile Platform got reinstalled, it half ignored its previous installation. It retained my Service Center settings, but the previously deployed eSpace got wiped out. It was a 404 when I brought it up, and on a publish from Service Studio its data got wiped out.

Do me a favor, start the Outsystems Contiguration Tool as a administrator, by right clicking on it

Then, check the database that outsystems uses. 10 to 1, it's now ending with a _
change it back to outsystems, press ok, and HOPE! that the credentials are still valid
Louis -

It's pointed to the right DB and it picked up the system settings right. It just seems to have treated the publish as a fresh version of the eSpace for whatever reason.

No big deal, it was my dev box, but it *will* be a problem if it happens to a production system...


well if you are sure that your DATA is gone, and not just your deployed espace, then try to check one last thing.
C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ <-- this should be the default location for your outsystems database

by default the system uses : outsystems.mdf & outsystems_log.LDF
if you have REMOVED the platform / SQL server in an attempt to fix your problem with updating *I'm still having issues*

you would see files like :

If that's not the case, then I would defenately have a "chat" with support if I where you.
In my experience it can happen that you loose the deployed espace, but with a redeploy/publish the original data should still be there and availible for your espace. as well as in DEV as in PRD.

Good luck.

I've begun to have similar issues accessing certain websites since installing SP1 onto my 2008 r2 DC/DNS server.  It is definitely a problem with service pack 1.  Yesterday my users couldn't access any sites with extensions.  This morning they were having a problem accessing all .org sites.  Both times I was able to temporarily fix the problem by clearing the cache on my DNS server. 

It must be a very new and relatively unknown problem because there is almost nothing on the web about it.  This is the only site that came up after many variations of google searches.

Go to your DNS server, open DNS and right click the DNS server in the list and select "Clear Cache".  It should fix the issue but it appears that somehow DNS is repeatedly becoming corrupt due to the SP1 update as I've had two different related problems on two consecutive days.

Judging from this thread the same happens on Windows 7 after installing SP1. If you are on a corporate network tell your admin about this problem and have them clear the DNS cache.  If you're having the problem from a home connection your only course of action might be to contact your ISP, inform them of the problem and hopefully they will clear DNS cache on their servers for you.  However, as I said, it will most likely happen again with another type of site and the problem may pop up on a daily basis until a hotfix is provided by Microsoft.

More than likely I'll be opening a ticket with MS.  I'm going to see how things go for the next week first.

Good luck!


Hi Tony, and welcome to our community forums.

I'm definitely looking forward to an answer from MS on this topic. Let us know what you found!


Paulo Tavares
I've found the following and it sounds like it "might" be the fix for this problem.  It doesn't specifically talk about 2008 R2 SP1 but the problem seems to be very similar.

Check your server registry first [HKLM\SYSTEM\CurrentControlSet\services\DNS\Parameters] to see if EnableEDNSProbes is already set to 0 before applying the fix and post back to let me know if was.  Mine was set to 1.
My problem was completely different, I was getting errors when accessing the espace, not DNS errors, but server side runtime errors above the .NET level.

I'm having similar issues; on a production server.
It seems like SP1 upgrade trashed some IIS modules or even the entire installation.
My console showed me I was missing both a DNS server and a IIS installation.

After (re)'installing' IIS all of the IIS settings (Pools & Applications) specific for outsystems seem to be gone.
I've added the ServiceCenter applciationpool and was able to start that.

I don't seem to be able to publish any application though:
I keep getting the error:

Unknown error (0x80005000)\r\nSystem.Runtime.InteropServices.COMException (0x80005000): Unknown error (0x80005000)
   at OutSystems.RuntimeCommon.OSDirectoryEntry.Exists(String path)
   at OutSystems.HubEdition.ServerCommon.Utils.PlatformUtils.CreateApplicationPool()
   at OutSystems.HubEdition.DeployService.Deploy.#e.#QSb.DeployEspace(String espaceName, Int32 espaceVersionId, String testAreaName, Boolean partial)
   at OutSystems.HubEdition.DeployService.Deploy.#iTb(String espaceName, Int32 espaceVersionId, String testAreaUser, Boolean partial, Boolean isMTeSpace, DateTime lastZipTimestamp)
   at OutSystems.HubEdition.DeployService.Deploy.#gTb(String espaceName, Int32 espaceVersionId, String userName)
  ExtraInfo  :
CompModule : Broadcast Message

Executing the ConfigurationTool gives me the following errormessage:

I've been able to configure the applications manually now and I can run the applications and reach my database as before.
Only I'm not able to publish anything thus not able to continue working on the applications.
I'm kind of in a twilight zone here...

Anyone has an idea on how to fix above issue and enable me to publish again and enable me to continue with this production environment?


Hi Eric,

Please make sure you also installed the "IIS6 Management Compatibility" feature of the IIS, as it's a requirement and can cause those type of errors.

João Rosado
Thanks for your post, João!; I'll check this soon and will post the result here.
This command just ruinned my configuration: it uninstalled IIS and after that I can't succed to reinstall it.  I am on W7 x64 SP1.

I was diverted to this thread because I have no success ever to install the Platform Server part of Comunity Edition.
Now I'm really stuck,
I really hope to avoid somehow to reinstall Windows.
Laurentiu, isn't running a WinXP install within a VirtualBox on your Windows installation an option?
I use that for development and it gives me options like snapshot creation which helps in doing upgrades.
Hi Laurentiu,

Well, let's not be drastic :)

My first suggestion is to go through our step-by-step guide on how to install the Agile Platform manually.

If that doesn't work out, do let us know what problems you face in a new topic - since this was specifically related to Windows Server 2008 R2 SP1, and not Windows 7.


Paulo Tavares
Well, I hope to be not so drastic. I was diverted to this thread by Renato. We try from long time to solve my unsuccesfully installation on Win7x64.

Well, after making a sort of naive remark about the OS (I just learned that Windows 7 = Windows 2008 + Media Services, give or take), I also talked to Renato and he should follow up with you.

Regards, and my bad about the OS remark :)

Paulo Tavares
As Renato allready know, I have an previous succesfull installation on W2K8, but after a full reinstall with SP1, also have troubles. At the moment I did'nt think to SP1 but it seems to be related.
But just in my case, the challenge is to have all working on W7x64, because I roamning much, not all the time I have net connection, so I want a notebook working installation as first choice.

Partial offtopic: I wondering if someone knows a (free ;-) ) tool for investiganting IIS health, somehow simmilar with best practice analyzer in W2k8 IIS.

I was on the phone today with a customer that had the exact same problem (in Windows 2008 R2 SP1, access to root level in all VDirs yielded a 500 error, but accessing a specific page/aspx would work OK).

We fixed the problem by:
  • Deleting all  Virtual Directories, one by one, in IIS;
  • In ...\Platform Server\running, deleting the folders and the .TimeStamp files;
  • Opening the Configuration Tool and clicking OK (allowing restart of all OutSystems services).
As soon as Deployment Service finished redeploying all eSpaces, the problem was gone.

If you are still having problems with IIS and Windows 2008 R2 SP1, can you try to do that?
Did it work?

Acacia -

I tried that, it didn't work. Thank goodness for VM snapshots. :)


You requested me to follow the install procedure.
I derived from that a bit.

I've executed the platform server install of a newer version.
This started and installed the IIS server (again).

After this the environment was completely fixed.
Thumbs up for you guys!

Regards and hope to see you @ NextStep!


Just had a call, another customer, same problem. This time I went a little bit lower-level on this problem, and detected a strange pattern - in the Handler Mappings of all Virtual Directories, there was an entry mapping to an extension: .* 

To solve it this time, I just removed this mapper.

And it seems that it is not just OutSystems users running into this:

Thanks Acácio, this solved a couple of situations where I was having this problem.

I've also tried to discover why the creation of this handlers is happening but wasn't able to find much on the subject. Best guess is that SP1 will need another service pack to fix what it has broke.

Best regards,
Well I have bad news.

Despite the fact that the procedure to remove the handlers makes the VDirs work as they are supposed to, as soon as you redeploy one espace the handlers of that espace are recreated and making it "unusable" again.

This quick fix can solve a production environment since there shouldnt be that many deploys any way, and you can delete the entries as soon as you make the deploy, but in a development environment it's not feasible to do so

Best regards,
Hi Pedro,

That is because you removed the handlers from the VDir, you need to remove it in the parents too (like the WebSite), since the handlers are inherited.

João Rosado

The parent (root vdir) doesn't have such handlers created.

Acácio while checking the IIS metadata already had come to that conclusion, no inheritage is passed to explain why the sub-VDirs have this behaviour.

Best regards,

Further investigation by our R&D (kudos to João Rosado) yielded that the problem with AboMapperCustom is caused by:
  • Having ASP.NET 4.0 registered in IIS;
  • Having handler ExtensionlessUrl* registered in IIS;
  • The way the VDirs are created by the Agile Platform.
So the immediate workaround is:
  1. Access IIS Manager;
  2. On the tree, click <computer>
  3. In Features view, open Handler Mappings;
  4. Remove Handlers associated with path *. ExtensionlessUrl-ISAPI-4.0_32bit, ExtensionlessUrl-ISAPI-4.0_64bit, ExtensionlessUrl-Integrated-4.0;
  5. Delete all Virtual Directories associated with eSpaces from IIS. Don't delete CustomHandlers, Dispatcher, SMSHandler;
  6. Delete the *.timestamp files in the running folder;
  7. Restart Deployment Service.

R&D will add an improvement to this behavior in an upcoming patch for the major versions that support Windows 2008R2.

Acácio & João Rosado: Kudos for both of you :)

I just did these steps and it's working...lets hope it stays that way when more publications will be done :)

We're glad to know it's working. Thanks a lot to you all for the helpful feedback throughout this process, and tons of thanks as well to João Rosado, Acácio, João Portela and Renato for all the investigations and long hours into nailing down what the problem was and how to fix it!

Great job :)

Paulo Tavares

Just yesterday a customer reported the exact same problem - but this time in Windows 2003 and IIS6.

So the setup was:
  • Agile Platform 5.1;
  • Windows 2003 & IIS 6.0;
  • .NET 2.0 and .NET 4.0 installed in the server, and both enabled in Web Service Extensions.
The problem was caused by feature ExtensionlessURL, and the symptoms were:
  • Access to http://server/eSpace/ yielded a 404 error;
  • Access to http://server/eSpace/_Default.aspx (or any other aspx) worked OK.
Documentation on this behavior can be found here: and instructions to disable ExtensionlessURL are found here: Cheers,

I would like to add that this problem has been addressed in the Agile Platform. The improvement is available since:
  • 5.0: revision patch;
  • 5.1: revision patch;

If you are affected by this problem, you should patch your installation to the revision patch indicated (or a higher one). After republishing all the components, the problem will be solved.

With best regards,
I had the problem Acácio reported here for the ASP.NET 4 breaking changes

In my case a simple registry key was the solution (for w2003 iis 6 v  (see below)

Here is the original post:

If you really need to have .NET 4 and .NET 2 , go through you app pool settings and make sure that each application is using the correct app pool and have the correct .NET version selected.
Because the .NET version is set on the app level, the first app started will determine the App pool .NET version also. From there all app that use that app poool must be set to use the same .Net version. A simptom of this is when you start getting error in the event viewer saying the app pool can not run diferent .net versions.
Then when you reset the app pool, all is well again.
Also check the desfault ASP version selection on the website level.

ASP.NET 2.0 Applications Might Generate HttpException Errors that Reference eurl.axd

After ASP.NET 4 has been enabled on IIS 6, ASP.NET 2.0 applications that run on IIS 6 (in either Windows Server 2003 or Windows Server 2003 R2) might generate errors such as the following:

System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.

This error occurs because when ASP.NET detects that a Web site is configured to use ASP.NET 4, a native component of ASP.NET 4 passes an extensionless URL to the managed portion of ASP.NET for further processing. However, if virtual directories that are below an ASP.NET 4 Web site are configured to use ASP.NET 2.0, processing the extensionless URL in this way results in a modified URL that contains the string "eurl.axd". This modified URL is then sent to the ASP.NET 2.0 application. ASP.NET 2.0 cannot recognize the "eurl.axd" format. Therefore, ASP.NET 2.0 tries to find a file named eurl.axd and execute it. Because no such file exists, the request fails with an HttpException exception.

You can work around this issue using one of the following options.

Option 3

If it is not practical to remap the Web site to ASP.NET 2.0 or to change the location of a virtual directory, explicitly disable extensionless URL processing in ASP.NET 4. Use the following procedure:

  1. In the Windows registry, open the following node:


  1. Create a new DWORD value named EnableExtensionlessUrls.
  2. Set EnableExtensionlessUrls to 0. This disables extensionless URL behavior.
  3. Save the registry value and close the registry editor.
  4. Run the iisreset command-line tool, which causes IIS to read the new registry value.