I have to export a classic asp/asp.net 2.0 web site that uses also coldfusion 8, from Windows Server 2003 with IIS6 to Windows Server 2012 and IIS 8.
I got everything working except setting up coldfusion to work with IIS.
The pages using coldfusion have .cfm as an extension.
I tried to follow this link here but that did not work
http://www.adobe.com/devnet/coldfusion/articles/iis-configuration.html
When I try to add the handlers in IIS, I see a warning saying this site is in classic mode and I need to manage managed handlers directly in the config file.
I tried to add the handlers using appcmd like this:
appcmd set config /section:handlers /+[name='cfmHandler',path='*.cfm',verb='*',type='c:\coldfusion8\runtime\lib\wsconfig\jrun_iis6.dll',preCondition='integratedMode']
Then I added the Wildcard Script Map in IIS as per the link, this seems that it created and entry in the web.config of the site.
<system.webServer>
<handlers>
<add name="JWildCardHandler" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\ColdFusion8\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll" resourceType="File" requireAccess="None" preCondition="bitness32" />
</handlers>
</system.webServer>
When I try to browse to the web site, if the wildcard handler exists in the web.config, I get error 404 on any page, even the one that does not end with .cfm
I removed the wildcard and I now get the following error:
Handler "cfmHandler" has a bad module "ManagedPipelineHandler" in its module list
Most likely causes:
Managed handler is used; however, ASP.NET is not installed or is not installed completely.
There is a typographical error in the configuration for the handler module list.
During application initialization, either the application initialization feature has set skipManagedModules to true, or a rewrite rule is setting a URL that maps to a managed handler and is also setting SKIP_MANAGED_MODULES=1.
I tried to run the fix that some programmers mentioned in other questions, but did not help
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis -i
I tried to add the handler in the web.config instead of doing it through appcmd but I got the same error.
<add name="cfmHandler" path="*.cfm" verb="*" type="c:\coldfusion8\runtime\lib\wsconfig\jrun_iis6.dll" preCondition="classicMode" />
I have been trying to get this to work for the last 3 days without luck.
All I need get done is to make any page that ends with .cfm handled by the coldfusion server. It's obviously the web site is old .NET and probably classisMode. I could not find simple step by step instructions other than the link above which did not work for me.
Thank you in advance
Related
Ok, so on my new site bob.testing.com, I set it up as anonymous authentication. Under it, i have a folder called apps. That's not an app, and there's no configuration on it. Under apps, I have a folder called MyApp. Originally, I set this up as Windows Authentication, but later I needed to update it to Anonymous. If I rename this folder to MyApp2 and create the application it works with Anonymous Authentication. When I rename it back... it sends back 401. I've tested with Fiddler, tried changing browsers, had someone else at work try it. Same results. I've tried recycling app pool, changing app pool, restarting IIS...
Anyone know how to delete whatever information IIS has cached about this application? I'd prefer not to have to rename and refactor my other apps for this item.
So, after posting; I actually looked here:
C:\Windows\System32\inetsrv\config\applicationHost.config
It was listed with two location path's. I ended up just deleting both and then setting it up again as an application. It appears to be working for now...
Looked something like this:
<location path="bob.testing.com/apps/MyApp">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
I have successfully deployed a Lightswitch HTML application to Azure Websites. I have also forwarded my personal domain to mask the azurewebsite.net address. I am now able to access the site by typing mydomain.com/htmlclient and everything works fine. If I type in just the my domain.com, however, I get the you do not have permission error.
This is close but ultimately I would like to be able to enter just the domain and have it automatically forward to the htmlclient folder. I know it is possible but I'm not sure if I can get there with settings in azure or my domain host or if I have to drop a page in the root (it appears that the default and login.aspx pages for forms authentication are already in the root).
Any help would be appreciated.
In the Visual Studio 2013 version we've found this is simply a case of adding an additional entry to the LightSwitch server project's web.config file.
This additional entry needs to reference the default.aspx file (which should already be part of the server project) and should be introduced into the defaultDocument section of the web.config. In the following example, this new line appears immediately after the standard default.htm line: -
<defaultDocument>
<files>
<clear />
<add value="default.htm" />
<add value="default.aspx" />
</files>
</defaultDocument>
I've installed the ImageResizer libraries in my DotNetNuke environment as described at http://imageresizing.net/docs/workswith/dotnetnuke
But I'm getting redirected to the root of my portal as soon as I call the resizer extension
My resize settings in the web.config look exactly the same as the example in the installation guide
<resizer>
<pipeline fakeExtensions=".ashx" />
<plugins>
<add name="MvcRoutingShim" />
<add name="DiskCache" />
</plugins>
</resizer>
Looks good to me, but as soon as i try to call an image through the extension, I get redirected to the root of the site.
Call to:
http://localhost/Portal/0/Image.jpg.ashx
Redirects to:
http://localhost/
I can't figure out how to fix this. Is it a DotNetNuke or a IIS setting?
Things I already tried:
Checked the Configuration of the site and made sure the .ashx extension has the "Verify that file exists" checkbox unchecked.
Tried using an other extension
Tried adding a wildcard in IIS
checked resizer.debug.ashx,
2 Issues detected:
(Warning): To potentially see additional errors here, perform an image resize request.
Server(Warning): Microsoft-IIS/6.0 does not support Integrated mode or does not have it enabled.
You must append the .ashx extension to any image requests you wish to process.
It seems the handler is never called and the redirect takes place based on the fact that there's no physical file called Image.jpg.ashx.
Any ideas how to fix this?
It was a defective rewriterule in SiteUrls.config causing this problem:
<RewriterRule>
<LookFor>[^?]*/(\d+)/(.*)</LookFor>
<SendTo>~/Default.aspx?tabid=$1</SendTo>
</RewriterRule>
I have a ServiceStack project with ServiceStack Razor added. Any time I try and navigate to the root of the site, I'm getting redirected to /metadata.
This does not happen on my dev machine, only in my hosted environment (AppHarbor).
I do have a Default.cshtml in the root of my project.
Navigating to other URLs work fine: /default1.cshtml, /myservicewithviews
I've tried messing with the DefaultRedirectPath in my AppHost, but that didn't help.
Trying to force it DefaultRedirectPath = "default.cshtml" result in a redirect loop. Which makes sense.
What is causing this?
AppHarbor only publishes files marked "Content" when building projects (AppHb FAQ). This file was the only one not marked content and why I was only experiencing this in my hosted environment and could access all other content.
Not detecting a default document causes ServiceStack to set a RedirectHttpHandler to /metadata - shown around here
Another noteworthy point is that AppHarbor's load-balancer causes their internal port numbers to show up in ServiceStack URLs when performing things like Response Redirects.
To fix this problem, you add the following to your Web.Config:
<appSettings>
<!-- AppHarbor Setting to stop AppHb load balancer internal port numbers from showing up in URLs-->
<add key="aspnet:UseHostHeaderForRequestUrl" value="true" />
</appSettings>
You could also configure this setting in your AppHarbor config panel.
We have a problem occuring on some of our developer workstations: when visiting a URL without a filename (e.g. http://localhost/), IIS 7 returns a 404 error. Everyone is running Windows 7/IIS 7.5 and ASP.NET 4.0. The application pool is configured to use Classic pipeline mode.
Default documents are enabled, and default.aspx is in the default document list.
I enabled failed request tracing, and see this in the log:
OldHandlerName="", NewHandlerName="ExtensionlessUrl-ISAPI-4.0_64bit",
NewHandlerModules="IsapiModule",
NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Later on, I see that this IsapiModule is rejecting the request:
ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="404",
HttpReason="Not Found", HttpSubStatus="0",
ErrorCode="The operation completed successfully. (0x0)", ConfigExceptionInfo=""
It looks like IIS thinks the ExtensionlessUrl-ISAPI-4.0-64bit should be handling the request. When I look at that module's configuration, it shows that it should be matching path *., so I'm confused why it is matching no path.
A Google search turns up this post on the IIS.net forums from 2005. Unfortunately, no solutions are offered, just an acknowledgement of the problem.
When I update my app pool to use integrated mode, the problem goes away. Unfortunately, it has to run in Classic mode.
What can I do to get IIS to server our default documents again?
It looks like Microsoft released an update that enables the ExtensionlessURL HTTP handler to work with extensionless URLs. Unfortunately, this breaks certain other handlers. In my case, the DefaultDocument handler under classic app pools. The solution is to remove the ExtensionlessURL handlers in our application's web.config:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrl-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrl-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrl-Integrated-4.0" />
</handlers>
</system.webServer>
I solved the problem with putting the "StaticFile" handler in HandlerMapping in front of "ExtensionlessUrlHandler-*"
I noticed when removing the managed .NET framework (4.0) from the application pool, it fixed the problem for me too!
We don't use .NET at all in our IIS environment!
I use the following rule in web.config URL Redirect as workaround to solve this:
<system.webServer>
<rewrite>
<rules>
<rule name="Default document rewrite" stopProcessing="true">
<match url="^(.+/)?$" />
<action type="Redirect" url="https://{HTTP_HOST}/default.aspx" />
</rule>
</rules>
</rewrite>
</system.webServer>
Changing the StaticFile order helped to fix the issue, when setting default document to a web site application in IIS, while the root website also had another default document.
Adding the DefaultDocument component to IIS in add/remove windows features and then inserting the name of my default script ( index.php) worked for me.