Due to a management decision, I recently used Data Access Pages to create an internal application on our intranet. At the time, we had IE 6.0 and Office 2003, and we're using DAP to connect to SQL Server 2005 (there is no local Access DB in this application). Now, Corporate is pushing IE 8.0 and we are having problems.

The copies of these pages that reside on my own laptop continue to work fine. However, I cannot get a database connection when the identical files are hosted on our tomcat server. They worked there fine with IE 6.0, but do not work with IE 8.0.
- When accessing using http, I get an error page instructing me to add the server to my trusted zone (where it already is).
- When accessing by double-clicking on the file in a share using Windows Explorer, the header appears and none of the rest of the page renders.
- When opening using Access, I get an error that some of the DB objects are missing, and the pane that shows the DB connection has a red icon next to the connection and the DB contents that are supposed to display in a tree are missing. If I select the connection and choose properties, then test the connection, the connection is fine. If I refresh the connection, it says there may be a problem with the connection string.

Why would there be a problem with the connection string when the page is located on the server, but not when the page is located on my machine (the HTML files are identical)?

I know as a last resort we can have IT revert our browsers to IE 6.0, but I'm hoping there's an alternative. Maybe a fully qualified domain name for the SQL Server in the DSN or something. Yeah, that's what I'll try next.

Rebeccah

Out of curiosity, does it makes any difference if you have IE8 view it in compatibility mode?

Also, another possibility is that it can't render properly due to ActiveX controls being blocked on the server itself, not on your client machine?

I tried (or thought I did - this is my first experience with IE 8, so it's possible I didn't set it correctly) compatibility mode before, but will try it again.

The pages all worked fine with IE 6.0, and nothing has changed on the server. It still has IE 6.0 and no OWC, so I really can't test it there. If it's blocking activeX downloads now, it should ahve been blocking them before.

Rebeccah

Yep, no difference with Compatibility View checked or unchecked. I've also reset the Trusted Zone security settings to default (and the server is in the Trusted Zone).

Rebeccah

Right, what I did not express clearly is that the upgrade to IE8 also tightened up the security and blocked ActiveX that were previously allowed on the server. Keep in mind I don't know much about the underlying technology and whether there are any server-side component in the picture but from what I know with SharePoint component, I've seen cases where my client machine can see stuff just dandy but my server can't see itself due to increased security and actively blocking looping back, so I extrapolated to here suggesting that it may be server side. Obviously if there aren't any server-side components for this DAP technology to function, then my suggestion would be off the mark.

I hope that helps...

Yeah, it's all client side.

However, you raise a good point that IE 8 tightens up a lot of security - possibly even in the trusted zone, so after I try a few other things, I intend to go through all of those settings one by one and see if I can't find something to "allow" that is currently being blocked.

It's also quite possible that I am seeing two different issues - the security page when I use http, and the failure to render when I simply double-click on the shared .htm file. If the http browser security problem can't be resolved, but I can resolve the rendering issue by changing a display property from "block" to one of the other values (as has been suggested in a couple of forum threads I've found), then we can just put a shortcut to the application on the users' desktops and forget about having them use http to access. It's an intranet after all, and we can make the files read-only so they can't accidentally corrupt them.

Rebeccah

OK, it looks like I'm on the right track. If I move the server from the trusted zone to the intranet zone, I no longer get the security page blocking me from viewing the DAP. Instead, I get a bunch of annoying popups I have to answer, confirming I really want to do this. So now, I need to compare security settings in the two zones.

Rebeccah

Now that jogged my memory -

A while ago I was walking through configuration with an SharePoint guru and he mentioned to me that unintuitively, Intranet zone is actually more "trusted" than Trusted zone. Bizarrely and I can't recall his explanation but for our configuration, we should be using Intranet while Trusted Zone really are only for external sites.

Hope that helps.

I was just thinking that might be the case...

I'm also scrouging around through my old e-mails - we had a similar accessibility issue when we first deployed with IE 6, with people following the instructions to add the site and then having the annoying popups. If I find the e-mail where I told everyone how to get rid of them, that should put the final nail in this.

Rebeccah

OK, now I've got it.

1. The web site hosting the DAP pages should go in the intranet zone, not the trusted zone (in IE 6, it worked fine in the trusted zone).
2. In the intranet zone, click Custom level and make sure the following are checked:
- Miscellaneous | Access data sources across domains: Enable
- User Authentication | Logon: Automatic logon with username and password
3. In the trusted zone, click Custom level to see what values you have. How much you trust computers in the trusted zone determines what values you select. I recommend:
- Miscellaneous | Access data sources across domains: Prompt
- User Authentication | Logon: Automatic logon only in Intranet zone


I suspect if you set the settings in the Trusted zone to enable and automatic logon, it would work fine there, too, but that would defeat the improved security of the settings.

If you set user authentication to "autologon only in intranet zone" in the intranet zone settings, it prompts you for logon (yes/no) just like it does in the other zones. You have to set it to "autologon" in the intranet zone to get it to not bother you with the popup. The options for this setting are kind of misleading.

Rebeccah

Glad you got it solved and thanks for sharing. I know I'll need to tuck that away for my own web applications in other cases. Thanks!