I have an ASP .net application hosted in server1 (win 2008 , IIS), on server 2 I have the same copy of that application (admin module), I have the session handled by ASP .net session handler. How can I determine who is loggedin In server1 app?
I want to see the alive sessions on server2.
How about writing the session in a database that both app has access to.
Related
I'm setting up an ASP.NET MVC5 application on a Windows Server 2012 VM running .Net 4.5 and IIS8. I've always leverages Azure for App and DB services (thank you Azure for your seamless 10 min server setup and publishing solution!) however I need to host this app using this alternative method. The VM is not an Azure VM. I've managed to configure the VM and publish the application (10 hrs of head banging experience... ) however when the application attempts to make a call to the Azure Db during the form registration process I receive a time out error; "The wait operation timed out".
My question is; I can access the application via the ip address from my local machine, I think port 80 is open by default. Do I need to specifically target this port in the applications web.config file for I/O calls?
If you want to connect a non-Azure Virtual machine which is behind a firewall to the resources in Azure, you will have to create a virtual network with either site to site or point to site VPN enabled. Please check this link which explains how to do it. https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-howto-site-to-site-resource-manager-portal/
Our (reasonably busy) intranet web site has recently been sometimes taking 2-3 minutes to log in users on the production server, and we haven't been able to find why.
The web site is a "top-level" web site (mapped to an IP address) containing an additional 10 virtual directories. The web site contains both classic ASP and ASP.NET pages, and is running .NET 4.0 (version 4.0.30319.235; the latest, I believe) and the entire site is HTTPS (SSL). It uses ASP.NET Forms authentication with an LDAP provider (the corporation's LDAP in the same domain). It's a very straightforward authentication, with an LDAP connection string and provider configuration in the root web.config, and an "asp:login" control, using the defined LDAP provider, on the login page. The web site is configured with wildcard mapping in IIS to allow the classic ASP pages to be authenticated with the same ASP.NET login process. Sessions are the default "Inproc", not using SQLServer or a state service.
Intermittently, starting about 3 weeks ago, it has been taking 2-3 minutes for users to log in to the web site. There are some pages in the site that don't require authentication and those still perform fine, and after loggin in, authenticated pages also work fine without any delays. It's only the login process itself that's slow.
The exact same website configuration and code running on the development server and workstations never encounters the same delays in authentication.
The login code has not changed in well over a year, and the site has been running .NET 4.0 for probably a year; the servers were updated to the latest .NET version in October-2010. The wildcard mapping was also set up well over a year ago. The login slowness only started about 3 weeks ago. The web server department is not aware of any changes that were made around that time to the web servers and/or the network.
While the long delay occurs on the login page, I don't think the delay is actually in the authentication process; it seems to be in some sort of setup before that. I have added the setting of a Session variable with the current date/time to the beginning (in the LogginIn event) and end of the login code, and there is usually less than a second between these times; however, the clock time between clicking the "Login" button on the login page and the setting of the first of these Session variables is a couple of minutes (consistently around 2 minutes and 14 seconds). I have tried this with page buffering enabled and disabled with no difference in the times.
The same configuration and code is set up in these various environments:
(OK) Development server: Windows Server 2003 SP2 64-bit (32-bit IIS) in SSL mode
(OK) Development server: Windows Server 2008 R2 64-bit (32-bit IIS) in SSL mode
(OK) dev. workstations: Windows 7 64-bit (32-bit IIS), NOT running SSL
(Sometimes slow) Staging web server: Windows Server 2003 SP2 32-bit in SSL mode
(Sometimes slow) Production web cluster: Windows Server 2003 SP2 32-bit in SSL mode
That is, in the development servers and workstaions, I cannot seem to cause the same slowness no matter what I try - resetting IIS, recycling the app pool, updating web.config, etc.
The development servers are using self-signed certificates for SSL; the staging and production servers are using "official" (Verisign) certificates. The production web servers are also used for other web sites (and the other web sites are all still at .NET 2.0), but none of those other sites are using LDAP authentication. All machines (production and development) are up-to-date with Windows Updates.
I can reproduce the problem on the staging or production servers by forcing an application restart (such as by updating web.config) or asking for an IIS Reset, or (on the staging server) waiting for more than 20 minutes with no activity (I think, for the application pool default lifetime to end).
We have checked the following:
The "machineKey" section in every web.config in the entire site is identical
The application pool for the site is set to .NET 4.0, and no other sites are using the same application pool
The application pool identity is "NETWORK SERVICE"
We have tried the following in production with no change in the occasional login delay:
Adding connectionProtection="None" to the LPAP provider configuration
Adding an "applicationName" to the LDAP provider configuration
Adding a port number (the SSL/secure port number) to the LDAP connection string
We have looked through Windows event logs and the IIS logs on the staging and production servers, without finding an obvious connection to the issue. The only possibly-related error that does sometimes occur is the following (that's been logged sometimes about a second before the login succeeds, not at the time that the "Login" button was clicked), however, this may also be because a previously-logged in session has timed out:
Event code: 4006
Event message: Membership credential verification failed.
Application information:
Application domain: /LM/W3SVC/ [...]
Trust level: Full
Application Virtual Path: /
Process information:
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Can anyone suggest any other troubleshooting ideas or potential configuration issues that should be checked or changed?
You can take a memory dump when the problem is happening, and then you use windbg do the analysis.
How to take memory dump:
http://support.microsoft.com/kb/286350
This blog has lots information about how to analysis memory dump
http://blogs.msdn.com/b/tess/
I have setup 3 VMs:
(A) Active Directory in Windows 2008 R2.
(B) Microsoft SQL Server 2008 Express in Windows XP SP3.
(C) IIS in Windows XP SP3.
Both the SQL Server and IIS are joined in the Domain but the host PC is not. I've also created a domain administrator user with administrator privileges in the SQL Server. I can ping/access all the VMs from each other and from the PC hosting the VMs. I can connect to the SQL Server VM using Windows Authentication in SQL Server Management Studio inside the IIS VM with no problem.
I created a very simple application in ASP.Net application hosted in the IIS VM that opens a database connection in the SQL Server VM. I've set the web site to authenticate via Windows Authentication only. Here is my connection string:
Server=DATABASE;Database=HAP;Trusted_Connection=True;
Here is code:
SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString);
using(connection) {
connection.Open();
}
I've also set "Trust this computer for delegation to any service (Kerberos Only)" in AD for the IIS VM.
It throws "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication." exception. If I change the connection string to this:
Server=DATABASE;Database=HAP;User ID=sa;Password=connectsql;
the application works fine.
I really need it to authenticate via Windows Authentication and not via SQL Server Authentication.
Note:
IIS prompts the user for his Windows credentials.
It's unclear to me whether you intend the application to authenticate as the logged in use, or whether you simply want to have the asp.net worker process be authenticated via AD.
If you want the user to authenticate with their account, then you need to set "imperasonate=true" in the web config. This will have performance ramifications, but that may be ok.
If you just want to authenticate via the worker process, then you need to set the identity of the worker process to a domain account.
I developed a e-commerce project. My project copies running on Server 2003 / IIS 6 with .Net Framework 4.0 .
Today, i have Server 2008 and IIS 7.5. Project is running normally but when i redirected https page, session is broken.
How do i fix it?
IIS creates different application pools for each http and https bindings. so session state will be different in each binding (protocol) so you can not access session from one protocol in other one, unless you set cookie in client machine or set cookie name for your session.
the simple solution is to set domain wide cookie in http page and retrieve it in https page!
I have IIS7.5 server (Windows 2008 R2) with a classic ASP page that sends a message to private queue that is located on another Windows 2008 R2 server.
The page refers to queue by its formatname:
DIRECT=OS:servername\private$\queuename.
The message is not delivered to the queue.
I checked firewalls - everything is open and nothing of note appears in the event logs on both servers.
If I run the same code in VBS file on iis7 server with the same credentials - the message is delivered to the remote queue.
If I send the message from IIS7 to a queue on Windows 2003 server - everything works just fine.
Additional details: The IIS7 site runs in an application pool with domain user credentials, the same user has full control permissions on the queue.
Thank you.
This will be a permissions issue on the destination queue.
Easy test is to give Everyone and Anonymous Logon full control temporarily to see if messages then get through