I have just released one of my application to production environment. Live environment has two IIS Servers via a Load Balance. The server configuration people has informed that they have implemented something called "Sticky Load Balancing" to carry out the sessions to IIS 1 or 2 via the Load Balance [Sessions are handled via the Load Balance].
Error
On accessing the website via IE9, I am getting a view state error. Screen Shot attached.
Exception
The exception is not being generated from Chrome Browser. But compliance requires us to tweak the application to IE9 only.
What Needs to be done to resolve the issue ?
The below post, although the person who asked it is not exactly facing the same situation, The solution which has been posted is valid for this, Especially the second point which says about defining a machine key for the application.
Please refer the below, i hope it helps.
Avoiding invalid viewstate when deploying on a load balanced website without downtime
Related
Currently I have an web application with web page (Redirect.aspx) with the following codes in its PageLoad function
Response.Redirect("https://redirectURL.com/folder1/folder2");
In my local debug, I'm able to reach the https://redirectURL.com/folder1/folder2 when i access the Redirect.aspx
However, when I hosted the web application (as Sample.com) in AWS EC2 server, when i access the https://Sample.com/Redirect.aspx it go redirected to https://Sample.come/folder1/folder2 instead of https://redirectURL.com/folder1/folder2.
Not sure whats triggering the change of website hence hope to get some helps.
Have found the reason. It wasn't due to code, it was because of IIS setting.
In ARR - Application Request Module, there is a "Reverse rewrite host in response headers" feature and somehow it was turned on hence causing the issue. Turning off this solve my issue.
I have a tough question here and I would like to tap the wisdom of the masses to ensure that I am approaching this issue in the most efficient way possible.
Goal: Move 78 web applications (all configured to be an IIS application under a root website) from a Windows Server 2003 box to a 2012 box with as little coding as possible. The 2012 box has a different subdomain "xxx2.blah.com" and the 03 server is mapped to a "xxx.blah.com" server. In short, the user bookmarks won't work once we migrate so we want to write a redirection utility to assist getting the users to the new xxx2.blach.com location without them noticing.
Current State:It is important to note that each application under the root website in IIS6 is configured to run under its own, and sometimes shared, app pools. Some of the applications have querystring values appended to the end of the .NET request that we want to retain because it affects the UI and other business logic already coded.
We were thinking of removing the files within each application to force IIS to return a 404. Once the 404 occurs, we were wanting to run our custom utility to lookup what the equivalent URL is. Since the 404 is an "error" by all intents and purposes, we were thinking that we could "handle" the error like this (ASP.NET 2.0 : Best Practice for writing Error Page)
Is it possible to write that code once, add the logic to the global.asax file in the root website, and then somehow instruct each web application under that root site to execute the code in the parent site? I know they each run under their own app pool and that may mean that we cannot pass execution off onto another application easily but I could be wrong. In addition, we are hoping to not have to copy/paste code 78 times. Any general "best practices" or advice would be greatly appreciated. Also, adjusting it on the network is not an option as the old xxx.blah.com is on a completely different network than the new xxx2.blah.com network.
#Carl
Thank you very much. I initially missed that those variables were available to me for this purpose! The final solution for me was to set the "Redirect To" textbox to "http://xxx2.blah.com$V?UpdateNote=true&$P". This enables the redirection to occur with both the path and querystring name/value pairs in tact and also allowed me to append my own value so that the application could detect it and display a "This page has moved" message to the user.
Thank you Carl! You da man.
I have an old ASP.NET intranet application where the forms login page is demonstrating unusual behavior. If any version of IE has a cleared history (history, not cookies) when they submit to log in the page executes a blank post back and remains on the login page.
If they refresh the page or had been redirected to the login page from trying to directly access another page then they are logged in without trouble.
I have published additional copies of this application to the same IIS server and they initially did not exhibit this behavior however after some number of hours they began acting the same way. Republishing to the same instance does not "fix" the issue like publishing to a new site does and neither does removing the old application and then publishing to the same name.
I'm not sure where to go from here so any help would be appreciated.
To me these are the key observations I have made:
This only effects our production server. The same code published to two other servers do not exhibit this defect. This code has worked for years until recently.
I replaced the button click code with a Response.Redirect to Google. When the button is not behaving correctly this redirect was not being fired. This indicates to me that the button code is not being executed. After the page is reloaded/refreshed it redirects properly since the button code is now firing.
When the same code is published to this IIS server under a different name it does not exhibit this defect for a number of hours. What could happen after a few hours to cause this behavioral change? Republishing to the same IIS site does not fix the issue for a few hours like publishing to a new IIS site does.
I have removed the button code from this posting because it is in my opinion a red herring as the code doesn't appear to be being executed at all.
This is what the cookies looked like in the network tools when the site is working
The difference here from when the site is working to when it is not working is that the Form1 key is marked as Sent and not Received.
Something new I have also noticed is that when the site is not working the favicon shows as (aborted). I now believe that the request is being completely aborted because I have overriden the page's OnInit and the code I entered is not being executed when the site is not working.
Today my work opened a ticket with Microsoft to help get this problem resolved and they have said it was a "head scratcher."
I disagree with Nick's thought that there is a problem in the code because of your assertion:
This only effects our production server. The same code published to two other servers do not exhibit this defect. This code has worked for years until recently.
This suggests there is a difference between servers, the way they are configured or the code is deployed that is stopping it from working. As it is a forms authentication problem, I am reminded of the bug that screwed up forms authentication in IE10 - see IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
Are your servers identical? Running the same OS, .NET versions, patches, hotfixes etc?
Microsoft saved the day.
They told us that the older versions of IE will look for the favicon in the root folder in IIS and not the application path regardless of where you're pointing it to look. There we found that the root folder's authentication settings were set to Windows Authentication only. For whatever reason this was causing the forms authentication to be aborted until we added Allow Anonymous to the root folder.
Our operator has implemented a Round Robin load balancer on our web portal and it seems to be causing some problems I can't get to the bottom of.
I'm able to identify which server we're on and as we navigate around the site we stay on server A. If I leave it for 5 minutes and try another page I'll get pushed to server B, logged out and shown the log in page.
I've got them to make sure the MachineKey in the machine.config is the same on both servers and I've tested locally that the session isn't being used - I can turn the session off completely locally and it still works. I've verified on both servers it is creating an ASPXAUTH cookie on the domain so we should be classed as authenticated on both servers - but keep loosing my authentication every time I change server.
Any ideas on what could be causing the logging out? I'm guessing it's my misunderstanding about how ASPXAUTH works.
Sessions are handled separately from Forms Authentication. There is a good explanation of this here.
The most common reason for Forms Authentication failures on load-balanced environments is lack of synchronization of the MachineKey element. You've stated that you've got the server operators to ensure that the MachineKey is synchronized, but have you verified this yourself in some way? Is this the case on ALL the web servers? From previous dealings with a couple of commercial web hosts, I've found that it is (unfortunately) difficult to take their assurances at face value.
Another thing to check is if the FormsAuthentication configuration (timeout, path, name, etc.) is the same on all of the hosts.
Are the patch levels the same on all of the hosts? You might want to see if the compatibility switch mentioned here is applicable in your situation.
Assuming that the hosting setup is correct, maybe you have initialization code on the page that logs you out if some condition is not fulfilled?
Try to take a look at the server logs and trace the sequence of HTTP requests involved during a failed page request. That might produce a clue.
Edit: This guide to troubleshooting Forms Authentication problems is detailed, and quite helpful: Troubleshooting Forms Authentication
Check for any other application functionality which depends on cookies. The web server on Server B will not recognize cookies that came from Server A. If any part of your authentication depends on cookies being populated, then that could cause your problem.
You have probably already ensured that the domain used for cookies is the same on all of the load balanced servers, but I thought I'd mention that. If the domains aren't compatible, then the browser will simply not send cookies to the server.
Our client recently complains that when they work on our production server, the user menu switch randomly, but this happens only occasionally .
The application has two types of user menu: regular user and restricted user. The target browser is IE. It's a ASP.NET3.5 application written in C#.
We can never reproduce this issue in our local environment. So it is very difficult to debug it.
Anybody met this type of issue or any clue how to debug it?
Web App Logging
Have you looked into adding a variable to your web.config to have your application perfrom less or more logging. I've done this in the past to track down bugs.
Client-side Logging
Perhaps not the intended use, but http://www.clicktale.com/ provides a javascript site analytics tools that can record all user mouse/keyboard activity that you could correlate to the web app logs. However it cost $$$.
Log Messages. Log them all over that has anything to do with the menu. Then the next time the user reports seeing it look at the log message.
Does the production environment use any load balancing s/w? Perhaps there is a problem with some session scope variables.