mellimik

Assuming this is a BHO (Browser Helper Object), the configuration should be stored at: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects If it's a Browser Extension rather than a Helper Object, it will be at: HKLM\Software\Microsoft\Internet Explorer\Extensions - both are per machine, rather than per user, although there may also be relevant data stored under the HKCU hive, which is specific to the user, not the computer (such as whether to display a toolbar, and what dimensions to make it). It is also possible to find extensions under HKCU\Software\Microsoft\Internet Explorer\Extensions, which would be per user, although this seems to be rare - and the fact that your add-in works fine for multiple users suggests that this is not the case here. It could be that the specific BHO/Extension you are using cannot be accessed by non-administrators. Perhaps some files are written somewhere that only admins have access to (such as the user profile of another administrator). For example, the Adobe Acrobat BHO installs a DLL at C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\AcroIEHelperShim.dll. If non-admins didn't have permission to read this file/directory, they would be unable to load the add-on. It might be time to dig out procmon.exe, and monitor what iexplore.exe is doing when you try to use/view the add-on as both admin and non-admin. Much appreciated for the reply. We actually got this issue sorted out by realizing that the problem lied in Local Group Policy. Some one or something had tampered with the security privilege called Create Global Objects. This privilege was assigned to BUILTIN\Administrators and one other group, where some users were members in. The browser add-in relied on this privilege, which was the actual problem. Or to put it another way, we had no problem. It was just that no one even thought of this kind of possibility.

Hi there. Would any one of you be able to share insight onto Internet Explorer and add-ons? Specifically, whether they are per user or per system? We have a bunch of Windows Server 2003 servers running with Terminal Services enabled. One software that people run while logged in is browser based, which requires Internet Explorer add-on to function correctly. The website contains a function to test if the add-on has been correctly installed. For some reason the site keeps saying that the add-on is installed when the user is a member of BUILTIN\Administrator, and the opposite if not. The Internet Explorer version we're using is 6 due to number of applications requiring it.

Thanks for the reply. I understand this a lot better now. I'll definitely take a look of this article.

We have a test user at the office who has been given a Windows 7 installation. He recently came to me to ask how can he add our network printers to his computer. The network printers are shared by our file server that is a Windows Server 2003 R2 installation. I told him to browse his way to the file server and choose Connect from the right click menu, but Windows is requesting elevation for some reason. He's running as a Power User, and even normal user should be able to do this, right?

I'll reply to myself since I now know what caused our problem with the RPC over HTTPS function. Basically my colleague had created a split DNS configuration of our AD integrated zone. Since the clients connected in the local office LAN use RPC and internal AD DNS zone to talk with the Exchange they have no problem, now for clients connected externally through the internet this caused issues, because the same DNS zone resolvable in the office LAN was suddenly resolvable from the internet as well.. just that it was a different server replying to clients which had no idea about the host name of the exchange server clients tried to resolve.

We've lately started seeing something out of normal behavior from our Outlook 2003 installations. Or then it might be that we've never really understood the application to begin with We use the combination of Outlook 2003, ISA 2006 and Exchange 2007. Clients connect using HTTPS outside of office network and then RPC while in the office. ISA is expecting HTTP basic authentication from the client protected using SSL. Outlook is configured to use HTTPS for slow and RPC for fast connections. For some magic reason we've never even had to bother our minds with this, things have just *worked*. Lately, though, Outlook clients connected outside of office have started to stall before prompting the user for credentials to proceed with login. And by looking at the Connection Status (outlook.exe /rpcdiag) we can see that for each connection made, it takes significantly long for Outlook to switch from RPC to HTTPS. So, I understand that this has to do with Outlook judging a connection either a slow or fast, which based on my Google skills seems to be 128Kb / s. What I don't understand is if this before mentioned value is the Adapter negotiated link speed or actually some calculated value between the Exchange/ISA server and the Outlook client? We have not changed anything since the original setup of our infra, so the Outlook acting differently is a bit mind boggling.. By looking at the Connection Status (see the attached image) it has always said Reg/fail being x/1 meaning it has always tried first using RPC then failed over to HTTPS. Now it just seems to take bloody long from it to do the fail over Has anyone else struggled with this issue?