Internet Explorer 7, Site Security, Mapped Drives argh!!

By sean.lannigan ·
A week ago Microsoft released Internet Explorer 7 and ever since then I have had a rash of security issues pop up as a result of the ?enhanced? security in IE7. I have solved all but one of them and this last one has got me absolutely boggled.

I have 50 ? 60 workstations running Windows XP SP2, Office XP with Access XP, and are all part of an AD domain. So naturally I control the security of the machines with Group Policies. The problem relates to zone security (Internet Zone, Intranet Zone etc) and mapped drives. Below is some info about the network environment so that I can give examples of my problem. This is only for explanation purposes and are not FQDN?s.


Primary Domain Server:


Mapped Drives:
M is mapped to \\\MY_DOCS\username
Q is mapped to \\\ADMIN

When I specifically go to \\\ADMIN through Start>Run it says in the bottom right corner that I am currently on my ?Local Intranet? (which is right) but when I goto Q it says I am currently on the ?Internet?. Now through a GPO I have set all the zones to their defaults (Medium-High for the Internet, Low for Intranet etc) and I have got all the checkmarks checked by default for ?Automatically detecting the Intranet? as well an a specific setting of ?* in the sites for Local Intranet. With these settings I can run MS Access files (as well as batch files, login scripts in VB etc.) if I go through the UNC path to get to the file but if I browse through the mapped drive I can?t. I get an error that says ?This file is located outside your Intranet or on an untrusted site. Blah blah blah.?

I have seen many people have this issue in my searches on the internet but they all refer to this issue when going through the UNC path and the solution is obviously to place the domain in the list of intranet sites. As I said above, that is what I did and it does work for UNC paths, but I HAVE to have it working for Mapped drives. There is no way I can go through the code in every one of my access databases and fix links that were originally created for the mapped drive, and not the UNC path. That would take me months. Believe me, if I had been the IT guy that originally setup this network, there would have been no Mapped Drives and everyone would be using My Network Places with policy enforced locations already there for the network shares. Unfortunately Mapped Drives is how everyone has accessed network files for 10 years on this network and training them to use UNC paths would be an administrative nightmare LOL 

I still have a couple of computers that have not upgraded to Internet Explorer 7 and they work perfectly fine. It has only been since the release of 7 that this started. I have also tried altering the entries in the sites list in various ways (file://*,, file://* etc) but they all have the same result as * so I can only assume that * would cover all the bases. I have also tried various configurations between Intranet Sites, and Trusted sites, but I get the same result no matter which one I use so I decided to keep it under Intranet Sites because that is what it is. I will also mention that this is not an issue for Access 2000 or Access 2003, but downgrading to access 2000 is not an option and Access 2003 is not in the budget until next year (which will most likely be Access 2007 by then).

Does anyone know of another way to force the system to treat a mapped drive as an Intranet Site? Keep in mind, I really need it to be a User Policy as opposed to a Computer Policy since Computer policies can?t be updated over my VPN connection, but User Policies can. I currently have all my remote users, logging in remotely over VPN and updating their Group Policy once a month. I can simply email them and tell them to update their policy after I get it fixed. Adding it to a vb script as part of the login process would work but still would require manual intervention for remote users, which normally don?t run the login script unless they are local.

I am praying someone here can help me with this problem.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

Solution as per Microsoft

by sean.lannigan In reply to Internet Explorer 7, Site ...

The solution is "This is a known issue with Internet Explorer 7". Well now it is anyway. After 6 hours on the phone with Microsoft they came to the conclusion that mapping a drive to an FQDN will not report the mapped drive as part of the "Local Intranet Zone" now if you map it to the NETBIOS name of the server it will work, but it causes a host of other problems with the way the rest of my network is configured so I was forced to scrap the network drives completely and start using policy controlled Shares in My Network Places. That was the route I was eventually going to go but I didn't want to be forced to go there so soon.

Oh well, the fun of being an IT Administrator. I just figured since the original post about the problem got pushed down the page so fast with other problems in the forum, that I would atleast post my findings after speaking to Microsoft.

Sean Lannigan
Hetek Solutions Inc.

Collapse -

What kinda worked for me

by geek49203 In reply to Internet Explorer 7, Site ...

What I did (and I don't have the VPN issues you've got) is to push out a REG file. I used Zenworks, and asked it to run the REG when the users logged into a workstation that IE7 installed.

Yes, it's a workaround. Yes, MS needs to fix this, but per MS, it's working as designed (I have a $245 bill to prove it).

Below are my reg entries -- obviously you'll change the name of the server for your situation:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\YOUR_SERVER]

Collapse -

I was going to do that

by sean.lannigan In reply to What kinda worked for me

Thanks for the reply. What I find funny is that the same problem happened to you that happened to me and they still don't have a fix released. The guy I talked to suggested that I do the registry stuff but I don't like using registry entries unless I absolutely have to. When he suggested it to me, I argued with him that if it worked before, and doesn't work now, it is Microsoft's responsibility to fix the problem, not mine to spend hours (or weeks) trying to find a work around solution because they screwed up.

I didn't win that arguement haha!! I ended up changing everything over to links in My Network Places replacing the need for Mapped drives (I should have done that after we migrated away from Novell) and although the transition was painful for some users, it is for a good cause.

However, I did get my phone charges credited. That was the first time I have ever had to phone microsoft about something and I imagine it is the last. If I have to call it is most likely something they aren't going to fix either LOL :)

Collapse -

more updates on my end

by geek49203 In reply to I was going to do that

M$'s India techs are driving me nuts trying to fix this. Could we just point them to your call? Do you have an incident ID?

I only have this happen w/ Access XP -- Access 2003 doesn't seem to have this problem.

Collapse -

workaround we use

by it.manager In reply to Internet Explorer 7, Site ...

We encoutnered this shortly after people upgraded to IE7.

A workaround is to get IE to not try and detect your local intranet zone.

- in Control Panel, run Internet Options
- Go to the Security tab
- Click the Local Intranet icon
- Click the Sites button
- Uncheck "autmatical detect Intranet Zone" box
- leave the others checked as per your preference (for me it's all three).

That should do it. To my recollection IE6 and belwo did not have this checked by default and IE7 does.


Collapse -

workaround we use

by cwomack In reply to workaround we use

Worked like a charm! Thanks!

Collapse -

Work around did not work for me

by dummy.address In reply to workaround we use

I set via policy to have all three boxes checked, but I still get the pop up.


Collapse -

Workaround works for us

by vendor_techrepublic In reply to workaround we use

Thanks Ryan... worked for us.
multiple mapped drives on Windows XP Pro SP3

Collapse -

Fully qualified names still does not work (ie DFS maps)

by techrepublic In reply to workaround we use

It works fine for those drives mapped to \\server\share, but we have a domain dfs link that is \\\dfsshare which still is viewed as an Internet zone. Assigning to the Intranet Zone via GPO fixes that problem, but may create others

Related Discussions

Related Forums