There are several problems that have been becoming more prevalent with iMIS 10.x.NET and iMIS15 involving various security and connection issues. Below, is a list of common issues and solutions:
These are becoming more common errors and are caused by several different possible problems:
- The User account has not been updated / synchronized with SQL security.
- The internet security settings on the local workstation are disabling cookies and/or blocking content from the intranet site.
- The 'sa' account has been locked out.
If this problem is restricted to one workstation, the problem is on the security settings for the workstation. Check the internet security settings:
- Open Internet Explorer and go to Tools >>> Internet Options >>> Security tab
- Change the highlighted "Zone" selection to "Intranet"
- Click the "Sites" button and add "http://IIS-SERVER-Name" to the list (change "IIS-SERVER-NAME" to the actual server name for your application server
- Once you've added this site to the list of "safe sites" be sure to double-check the actual security settings on the main screen
- Since this is only for the "Local Intranet" zone, you can change the settings for this zone to "Default Level" and crank the security dial all the way down to "Low"
- While you're messing around in the tools area, be sure to change the settings on pop-up blockers to allow pop-ups from the same site. This will prevent problems with IQA and other .NET-based items from happening before they start
- Don't forget Google or MSN toolbars with built-in pop-up blockers!!
Try rebuilding the SQL security:
In 10.x.NET:
- Log in as MANAGER!SA
- Go to File >>> System Setup >>> User Passwords
- Click on "Rebuild SQL Logins at the bottom of the screen. It's recommended to try this twice, since I've found there may often be some hangup on the first run that you never see.
In iMIS15:
- Open the iMIS DB Repair Utility
- Connect to the database through the SQL 'sa' password
- Click "Prepare iMIS Database" at the bottom of the screen
Check / change the Login security setup for the 'sa' account (this is exclusively an issue in SQL Server 2005):
- Open the SQL Studio
- Connect to the SQL Server using "Windows Authentication"
- Under the Object Explorer, expand the "Security Folder" and click on the "Logins" folder
- Right-click on the 'sa' login and select "Properties"
- On the Login Properties - sa pop-up window, on the "General" page, make sure that the checkbox for "Enforce password policy" is UNchecked
- Switch to the "Status" page, and make sure the "Enabled" is selected under Login: and that the "Account is locked out" checkbox is UNchecked
It's also a good thing to make the following change in the Web.config file under the .NET website
Web.config file locations:
- 10.x.NET = Program Files\iMIS.NET\web.config
- iMIS15 = Program Files\ASI\iMIS15\Net\web.config
Find the following line under the tag:
Change "false" to "true" so it now reads:
This will allow you to get the "Blue Screen of crazy code" whenever there's a website problem. It's actually much more useful than the standard custom error that pops up: "An error has occurred. Please contact your system administrator."
While you're in the web.config file, you might as well change one other tag:
Change the Max Results number on the PagedView list to 5000, 50000, or 500000, depending on the size of your database:
Change the number inside the quotes after value=:
This affects the limits put on all the screens in IQA results lists. This way, you can see the actual number of results from a query if that number is over 500. It quickly becomes annoying to run every query and keep getting "Showing 1-10 of 500" results, when in fact, there are 12,283 records returned by the query.
I'll add to this list as we come across more issues
-K
enSYNC Corp.
www.ensync-corp.com
Debug is not a good idea in production
>> Change "false" to "true" so it now reads:
That's a great idea during development, but can produce some serious information leakage in production. (For that matter, even in a publically-accessible dev environment.) The error messages returned by this area (and also <customErrors mode="Off">) reveal a lot of information useful to an attacker (whether human or scripted).
Setting customErrors to "RemoteOnly" is fairly safe. You can only see the errors when you are at the webserver console or browsing inside a Terminal Services session on the server.
Also, debug information can greatly increase the page weight. If the problem you're experiencing is a heavy server load, adding debug info to the mix can be a cure worse than the disease.
-- Bruce