Link to home
Start Free TrialLog in
Avatar of Michael Bentfeld
Michael Bentfeld

asked on

Why won't user login information transfer to ASP page after migration to new server?

Hello,

I've run up against a problem I can't solve after lengthy research. I have a legacy ASP site (used for filing warranty claims) on a Server 2003 32-bit machine running IIS 6.0 that I'm moving to a Server 2008 32-bit machine running IIS 7.0 due to Server 2003 EOL. Unfortunately I don’t have much programming experience so that doesn’t matters.  The site prompts users for their credentials, authenticates them with AuthentiX authentication software against an MS Access database (connected via ODBC DSN), then upon successful authentication takes said user to the first ASP page. As the site is supposed to work (and does on the old server), the User ID (Dealer Account) is shown on the page, along with two fields for entering an email address and a serial number. When the user clicks "Continue", the page verifies the Dealer ID and serial number against a SQL database on the same server (also connected by a ODBC DSN), and the dealer ID again against our ERP database on a separate SQL server. The site proceeds to the next page for additional info if successfully verified (warnings are shown if either entry is not verified). However, I can't even get that far. When I click "Continue" after entering a valid serial number (and my own email address), I get a warning that a required field isn't filled out correctly, which happens to be the User ID/Dealer Account (see below).

 User generated image

Open in new window


 I suspect there's a connection issue with one of the databases, but haven't been able to pin it down because I'm getting no other errors. The Access DB for initial Authentication is in MDB format, and the SQL database on the new server is now SQL 2008R2 (migrated from SQL 2005).

After checking with Google and various user groups, I did find the ‘validate.js’ script that was causing the error message, which I will be attaching to this post.
For some reason the User ID/Dealer Account doesn’t seem to be getting captured from the login popup and/or getting passed on the ASP page, or possibly the SQL.  I’ve checked that Everyone has Read access to AuthentiX and the web page.  All of the SQL logins have been copied over as part of the backup/restore, except for one labeled OLD SERVER\IUSR (though I have NT AUTHORITY\IUSR on the new server in its place).  I suspect though that there may be a login or connection either to SQL or another database that I’m missing somewhere.  I’m attaching a Word document with the code for the ASP page as well as a text-file version of the Javascript page that generates the popup.  Anonymous Access is enabled on the new server and the old.
Thanks for any help or insight anyone can provide.
Find-the-Current-User.docx
validate.txt
Avatar of David Johnson, CD
David Johnson, CD
Flag of Canada image

ODBC DSN << make sure that you've configured the 32 bit version properly and are not using the 64bit version.
Avatar of Michael Bentfeld
Michael Bentfeld

ASKER

I'm sorry, but I don't understand.  Both servers use 32- bit operating systems.  My apologies for not having explained that better.  I'll double-check the DSN settings over the weekend though and advise by Monday.
SOLUTION
Avatar of Michael Bentfeld
Michael Bentfeld

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I'm not a developer but can you comment the following lines of code?
if (!bReturnValue && i>0) {
			alert("You have not filled in "+elemmissed+" of the required fields correctly. \n Please correct RED colored items.");
			elem.elements[elemfocus].focus();
			return false;

Open in new window

The idea is to check what happens if this validation isn't made.
Thanks for the input, Vitor.  To be honest, I'm not a developer either, so all of this has been a "crash course" of sorts.  Sorry for the late response but I've been sick lately.  I tried commenting out the JavaScript as you suggested.  When I tried running the page and clicked on the Continue button, nothing happened, since the Dealer Account/UserID was still blank.  Apparently despite my rechecking of the user accounts and permissions for the SQL database, and the operation of the AuthentiX authentication software, the UserID information is still not being transferred over from the popup window where it is being entered for AuthentiX to that first page for the site.

If asked, I can post the full validation JavaScript file as soon as I have a chance.
I tried commenting out the JavaScript as you suggested.  When I tried running the page and clicked on the Continue button, nothing happened,
Can you re test and check if a connection to SQL Server was made from the webpage? You can check that by running sp_who2 command in SQL Server side.
It doesn't look like a connection is being made to the server at all.  I tried again and ran the sp_who2 command on the SQL server as you suggested.  I ran it on both the warranty sql database on the web server and the ERP SQL database (which is referenced in the ASP code as XXXXX5).  The closest thing I could find is the sql on the web server showed the ReportServer (error reporting) database awaiting a command.
The closest thing I could find is the sql on the web server showed the ReportServer (error reporting) database awaiting a command.
This mean it connected and maybe processed some commands and now is awaiting for some commands more.
Do you know how to work with SQL Profiler? Would return more information but at least you'll have the history of all commands executed on the database.
I'm afraid I haven't worked with SQL Profiler in a very long time.  Sounds like it's time to get reacquainted with it.  Thanks again for your help.
Go to MSDN article about How to use SQL Profiler. Will be a good refresh for you ;)
Sorry for the poor correspondance, but I've been tied up with several other projects besides this.  I've tried running SQL Profiler, both with the new site and with the current version.  It's difficult to say whether I'm having any better luck with the new site.  I'm not seeing any evidence of a connection with the new server to our MRP server for verification of CustomerID.  Running it on the new server doesn't seem to indicate anything either.  I can't run it on the current web server, as that only has SQL 2005 Express, which doesn't have SQL Profiler available.  There is a difference in SQL Logins between old and new servers.  The old server has a (servername)\IUSR login and (servername)\MSSQLSERVER login, whereas the new server has NT SERVICE\MSSQLSERVER and NT AUTHORITY\IUSR logins.  However, if my research is correct, the new server accounts and old server accounts are equivalent.  I did save the trace files and can upload them if anyone thinks it'll help.
I can't run it on the current web server, as that only has SQL 2005 Express
You can run a SQL Profiler remotely, i.e. you can run from the another server and connect to the MSSQL 2005 instance.

I did save the trace files and can upload them if anyone thinks it'll help.
Yes you can. I'm more interested in which trace are you collecting.
I'm attaching the trace files.  There are two referring to 202A (the server where the ERP system database resides).  The one with "new" in the title is from the test run I did with the new web server, which has its own trace file (marked "204a").  The other 202A trace file was run with a test transaction I did with the current server (trace file marked "204") for comparison.  The 202A trace files are filtered to exclude transactions marked as coming from our ERP application.  Sorry for the late reply but I got hammered with many other issues today.
202a-trace-edited.xml
new-202a-trace-edited.xml
204-trace.xml
204a-trace.xml
Did you add Warning and Errors events in the trace configuration?
What I can see from the traces is that you're using different users. Why are you using NT AUTHORITY\SYSTEM for 202A?
Unfortunately I forgot to enable those options.  I just re-ran traces for new test transactions (for exisiting and new systems) and will post shortly.  As far as using NT AUTHORITY\SYSTEM, I can't explain directly (I did not set up the server in the first place).  When I connect to it, I use the domain administrator account (not a local account).  It's odd, though, because the site code calls for connecting to the 202A database using the "sa" account (which I've always been told isn't good practice, but I didn't set up the original site either).  I've tried setting up a separate login for the database with the necessary rights and altered the code accordingly on the test system, but haven't had any luck.
204-old-wdb-test-7-13-15.xml
204a-new-wdb-test-7-13-15.xml
202A-old-wdb-test-7-13-15.xml
202A-new-wdb-test-7-13-15.xml
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Suggested feedback on user accounts was forwarded to my superiors.  This issue is now out of my hands, unfortunately.  I will advise when I find out what the ultimate solution is/was.