Category Archives: Uncategorized

ASP.NET MVC 3 Extension less URLs on IIS 6

The part that makes it easier has nothing to do with ASP.NET MVC 3 and everything to do with a little known new feature of ASP.NET 4 creatively called the ASP.NET 4 Extensionless URL feature. ASP.NET MVC 3 requires ASP.NET 4 so it naturally benefits from this new feature.\r\n\r\n\r\nIf you have a server running IIS 6, ASP.NET 4, and ASP.NET MVC 3 (or even ASP.NET MVC 2), your website should just work with the default extensionless URLs generated by ASP.NET MVC applications. No need to configure wildcard mappings nor *.mvc mappings. In fact, you don’t even need to set RAMMFAR to true. RAMMFAR is our pet name for the runAllManagedModulesForAllRequests setting within thesystem.webserver setting in web.config. You can feel free to set this to false.\r\n\r\n

<modules\r\nrunAllManagedModulesForAllRequests=”false”/>\r\n

\r\nWhen installing ASP.NET 4, this is enabled by default. So if you have a hosting provider still using IIS 6, but does have ASP.NET 4 installed, then this should work for you.\r\n\r\n\r\nHow does this work?\r\n\r\n

Here is how the v4.0 ASP.NET extensionless URL features works on IIS 6.  We have an ISAPI Filter named aspnet_filter.dll that appends “/eurl.axd/GUID” to extensionless URLs.  This happens early on in the request processing.  We also have a script mapping so that “*.axd” requests are handled by our ISAPI, aspnet_isapi.dll.  When we append “/eurl.axd/GUID” to extensionless URLs, it causes them to be mapped to our aspnet_isapi.dll, as long as the script map exists as expected.  These requests then enter ASP.NET where we remove “/eurl.axd/GUID” from the URL, that is, we restore the original URL.  The restoration of the original URL happens very early.  Now the URL is extensionless again and if no further changes are made\r\n

\r\nHe also has a list of conditions that must be true for this feature to work. If any one of them is false, then you’re back to the old extensionfull URLs with IIS 6.\r\n\r\n\r\nI’m Getting a 403 Forbidden\r\n\r\n\r\nThis is not technically related, but if you face 403 Forbidden error message. Here is how to fix it.\r\n\r\n\r\nIn IIS Manager, right clicked on the Web Services Extension node and selected the menu option labeled Allow all Web Service extensions for a specific application:\r\n\r\n\r\n\r\n\r\n\r\nIn the resulting dialog, select the ASP.NET v4.0.30319 option.\r\n\r\n\r\n\r\n\r\n\r\nTo double check that everything was configured correctly, look at the properties for my website and ensured that Scripts were enabled.\r\n\r\n\r\n\r\n\r\n\r\nAlso click on the Configuration… button and made sure that *.axd was mapped to the proper ASP.NET ISAPI DLL (aspnet_isapi.dll).\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\nWith all that in place, able to run standard ASP.NET MVC web application and make requests for /, /home/about/, etc. without any problems!\r\n

Hello world!

Welcome to Community\r\n\r\nWelcome to SysAdmin community site. You’ll get help, news, discussions and collection of tools for System administration & IT Professionals. The target is to make this community to be one of biggest community of System Administrators and IT Professionals.

Windows 7 Network Disconnects When Idle?



Windows 7 Network Disconnects When Idle?

I am having an issue with the network interfaces (both wired and wireless) disconnecting when the computer is idle for some period of time (~15 minutes from what I’ve observed).
This happens both when the computer is plugged into a power source and when running off the battery. It appears the computer is actually turning the interface off (link light on switch port goes off, and WAP shows no association). When the computer is no longer idle (kb/mouse input), the interfaces do automatically come back online without further issue.
Having active network traffic (eg. keepalives sent every 60 seconds by an app, like PuTTY) does not prevent the idle timeout from killing the connections. I have verified with a packet sniffer on the remote server that the keepalives are indeed being sent (at least until the interface gets shut down on the laptop).
Hardware: Dell Latitude E6400
Wired NIC: Intel 82567LM (driver version 10.0.6.0)
Wireless NIC: Intel WiFi Link 5300 (driver version 12.4.1.4)
Software: Windows 7 Enterprise 64-bit (functionally equivalent to Ultimate version) w/ current OS and driver updates/patches
Dell support responded saying Windows 7 is too new and referred me to Microsoft. Microsoft support responded with a couple of power saving config changes (described below) which did not work. Google searches have all yielded one of two answers – the Microsoft suggestion and a registry hack (also described below).
Per Microsoft Support:
- Control Panel -> Network & Internet -> Network Connections
- Right-click on desired interface, and select “Properties”
- Click the “Configure” button on the interface properties
- Under the “Advanced” tab, look for power-saving related options and set to “Disabled”
- Under the “Power Management” tab, uncheck “Allow computer to turn off this device to save power”
- Save & Reboot
Also per Microsoft:
- Control Panel -> Hardware & Sound -> Power Options
- By the selected power profile, select “Change Plan Settings”
- In the “Edit Plan Settings”, select “Change advanced power settings”
- Under Wireless Adapter Settings -> Power Saving Mode, set options to “Maximum Performance”
- Save & Reboot
Per suggestions found on Google:
- Regedit: HKLMCurrentControlSetservicesLanmanServerparameters: DWORD: autodisconnect = 0xffffffff
- (same thing as running “net config server /autodisconnect:-1″ from command prompt)
- Save & Reboot