Trying to investigate an issue a customer is facing where he gets a generic IE9 error - "Internet Explorer cannot display the webpage". We have ruled out connection settings as a potential cause, is there any to get a dump/snapshot of the security settings on this customer's computer?
I already saw some threads on the forum regarding gpedit.msc (here); however when I did a dry run on my system I am not seeing the information that I expect. I.e. the operation is not recursive and the few sites in my trusted/blocked list do not show up either. Is there a better method?
Vin
Related
Good morning all!
I am a sysadmin with a medium-sized business. I'm in workstation support, not part of the web team or server support. I have a single user who gets an information bar at the bottom of IE every time he opens our own company's homepage:
Internet Explorer blocked this website from displaying content with security certificate errors.
I am pretty sure this is a workstation issue, and not serverside. I cannot replicate the problem on any of our other machines. The browser still navigates out to the site, it doesn't show the "There is a problem with this website's security certificate" page and try to block access.
I have opened the certificate by clicking on the padlock icon in IE and I can't see any warnings about the certificate. Did the same in Chrome and can't find any issues.
I did a Clear SSL State in IE on the user's machine, and the issue still isn't resolved. Other HTTPS sites work appropriately.
As this is our own URL, it is a trusted site in IE by group policy. I have checked that the same is true on the user's machine.
At this point I am not 100% sure that there isn't actually an issue I need to report to the web team. Nothing I have tried seems to be able to clear this single machine of the notion that something is wrong with that certificate but I can't confirm it either way.
The website's URL is https://www.ruffalonl.com/
Assuming nothing is wrong with the site or the certificate, does anyone know a way of suppressing the blasted message in IE? Either I make this message go away, or I am going to get a support ticket from this user that says something is wrong with the website every single day until I die.
hi
i have a problem at my production site, client reported that he is not seeing data in lists of sharepoint, as well drop downs which have years in pages of site appear empty with one user A on machin X having with windows 7. but data and comes up and drop downs are now populated when accessed from machine Y with same user A.
i dont knw wht really the problem is. As to development site this issue is not produced,
plz help,
thnks in advance
From your question, I gather the data does exist and the same user can see the information from one computer but not another.
A couple things spring to mind. (I am presuming usage of Internet Explorer since SharePoint 2007 has some rather weird rendering issues with other browsers. Correct me if this is an incorrect assumption.)
First, Windows 7 has later versions of IE which can refuse to send network credentials to a server it doesn't think is part of the intranet (corporate network). What makes this especially frustrating is that IE will prompt for network credentials (a result of the challenge from the website) but will not transmit those credentials. Examine the IIS logs to see if this is the case. The requests will be void of credentials using IE but will be present using Firefox (and presumably any other web browser). The fix for this is usually as simple as adding the domain into the Local Intranet zone in Internet Options.
If this is not the case, can you confirm the user is using the same credentials? Is this integrated authentication using Active Directory or forms authentication?
Are there any differences between the two computers with regards to how they reach the SharePoint site? (Such as one is VPN, the other is directly connected)? Or are they essentially equal but with different browser/OS configurations?
Are the lists standard out-of-the-box lists or have they been customized with SharePoint Designer or any other means? Are you injecting JavaScript via a Content Editor Web Part which might not be executing correctly?
It would be very helpful to know browser versions used, OS versions used, differences in connectivity to the resource from each machine, type of authentication used, and any other thing you can think to list.
I wish you luck in tracking this down!
Windows 7 or xp has nothing to do over here probably it has to do with the browser which he is using to browse the site ask him to chk the internet explorer settings and verify that he has enabled execution of javascript and other related things
Sometimes the style sheet disappears when naviguating on our WSS 3.0 sites (white background on the site, no colors, no formatting, etc.). This has mainly happened with IE6 (corporate browser for the majority of our computers). The fixes were :
clean up temporary internet files
if it still doesn't work, upgrade to IE 7
However, this time, the upgrade to IE 7 hasn't worked, the style sheet isn't applied. When we clean up temporary internet files, things go back to normal, but after a while the css disappears again.
Here are a few ideas on what you could try:
Fiddler should be able to tell you if there is a network problem.
Check the HTML for anything unusual. Is it malformed in any way? Can you save a copy and run it through an online validator (although this is limited in use as SharePoint's default markup isn't compliant).
If some users are having the issues but others aren't, check their permissions on the server.
You could also try using the SharePoint "Log in as another user" feature to see if the problem can be reproduced on your machine when logged in as them. You may also want to try running Internet Explorer as that user.
Check the Event Viewer on both client and server for anything unusual.
Check the IIS logs on the server for any errors.
Check the SharePoint ULS logs on the server in the "12 Hive" for errors that might be related to this problem.
Try running Process Monitor on the client and reproduce the problem. Search for keywords such as FAIL or ERROR to see if anything appears. Make a note of the time the problem occurs and see if the Process Monitor logs give any additional information.
Is there some javascript that's involved as well? Could it be a virus scanner that is set way to strict? As you pointed out in one of the comments, the CSS isn't even being requested (at IIS log level, which is as basic as you get, not even in SHarePoint yet), so it HAS to be something on the client PC.
A cheeseburger to the first person who can help me make sense of this. I have a page in a Sharepoint app that uses Telerik's RadUpload to upload files. This has worked for months; last week it stopped working (in Internet Explorer, this detail is important). After talking with a co-worker about the problem, I tried the upload with Firefox; it worked. Not only that, all subsequent uploads from Internet Explorer started working. Flash forward an hour, and the aforementioned coworker, on another Sharepoint site, running on different servers, was having problems downloading (using Internet Explorer). Being half serious, half smart-aleck, I said 'try it in Firefox'. Not only did that work, ALL SUBSEQUENT DOWNLOADS IN INTERNET EXPLORER WORKED! And he re-produced this behavior on another machine. My fear is that this a browser issue. All advice will be greatly appreciated.
a
IE will try and present credentials to a server it knows to be in its Local Intranet zone when it tries to connect (depending on the setting of "Automatic logon only in Intranet zone").
Firefox will only present credentials when prompted, and will generally ask you by popping up a box (unless you've configured a list of sites for it to always present NTLM credentials to).
I've seen a similar case with Sharepoint where you can cause IE to work by logging in with Firefox. I theorized it was due to a permission on a remote resource being for "Authenticated Users", and you're causing your user to authenticate by logging in forcefully. We eventually set the "Automatic logon only in Intranet zone" to "Prompt" and it worked. My theory there was that it wasn't detecting the site as being in the Local Intranet zone for some reason. If you're not accessing a domain with no .'s in it, try also setting your Local Intranet site policy to match the full domain of the Sharepoint server, not just *.example.com - I've read that that can help.
Was it as simple as IE not re-downloading miss-cached .js file, maybe, that firefox did download, making IE work after that?
Pretty gnarly to debug.
I know this might be a no-brainer, but please read on.
I also know it's generally not considered a good idea, maybe the worst, to let a browser run and interact with local apps, even in an intranet context.
We use Citrix for home-office, and people really like it. Now, they would like the same kind of environment at work, a nice page where every important application/document/folder is nicely arranged and classified in an orderly fashion. These folks are not particularly tech savvy; I don't even consider thinking that they could understand the difference between remote delivered applications and local ones.
So, I've been asked if it's possible. Of course, it is, with IE's good ol' ActiveX controls. And I even made a working prototype (that's where it hurts).
But now, I doubt. Isn't it madness to allow such 'dangerous' ActiveX controls, even in the 'local intranet' zone? People will use the same browser to surf the web, can I fully trust IE? Isn't there a risk that Microsoft would just disable those controls in future updates/versions? What if a website, or any kind of malware, just put another site on the trust list? With that extent of control, you could as well uninstall every protection and just run amok 'till you got hanged by the IT dept.
I'm about to confront my superiors with the fact that, even if they saw it is doable, it would be a very bad thing. So I'm desperately in need of good and strong arguments, because "let's don't" won't do it.
Of course, if there is nothing to be scared of, that'll be nice too. But I strongly doubt that.
We use Citrix for home-office, and people really like it. Now, they would like the same kind of environment at work, a nice page where every important application/document/folder is nicely arranged and classified in an orderly fashion
I haven't used Citrix very many times, but what's it got to do with executing local applications? I don't see how "People like Citrix" and "browser executing local applications" relate at all?
If the people are accessing your Citrix server from home, and want the same experience in the office, then buy a cheap PC, and run the exact same Citrix software they run on their home computers. Put this computer in the corner and tell them to go use it. They'll be overjoyed.
Isn't it madness to allow such 'dangerous' ActiveX controls, even in the 'local intranet' zone ? People will use the same browser to surf the web, can I fully trust IE ?
Put it this way. IE has built-in support for AX controls. It uses it's security mechanisms to prevent them from running unless in a trusted site. By default, no sites are trusted at all.
If you use IE at all then you're putting yourself at the mercy of these security mechanisms. Whether or not you tell it to trust the local intranet is beside the point, and isn't going to affect the operation of any other zones.
The good old security holes that require you to reboot your computer every few weeks when MS issues a patch will continue to exist and cause problems, regardless of whether you allow ActiveX in your local intranet.
Isn't there a risk that Microsoft would just disable those controls in future updates / versions ?
Since XP-SP2, Microsoft has been making it increasingly difficult to use ActiveX controls. I don't know how many scary looking warning messages and "This might destroy your computer" dialogs you have to click through these days to get them to run, but it's quite a few. This will only get worse over time.
Microsoft is walking a fine line. On one hand, they regularly send ActiveX killbits with Windows Update to remove/disable applications that have been misbehaving. On the other hand, the latest version of Sharepoint 2007 (can't speak for earlier versions) allows for Office documents to be opened by clicking a link in the browser, and edited in the local application. When the edit is finished, the changes are transmitted back to the server and the webpage (generally) is refreshed. This is only an IE thing, as Firefox will throw up an error message.
I can see the logic behind it, though. Until Microsoft gets all of their apps 'in the cloud', there are cases that need to bridge the gap between the old client-side apps and a more web-centric business environment. While there is likely a non-web workaround, more and more information workers have come to expect that a large portion of their work will be done in a browser. Anything that makes the integration with the desktop easier is not going to be opposed by anyone except the sysadmins.
The standard citrix homepage (or how we use it) is a simple web page with program icons. Click on it, and the application get's delivered to you. People want the same thing, at work, with their applications/folders/documents. And because I'm a web developer, and they asked me, I do it with a web page... Perhaps I should pass the whole thing over to the VB guy..
Ahh... I know of 2 ways to accomplish this:
You can embed internet explorer into an application, and hook into it and intercept certain kinds of URL's and so on
I saw this done a few years ago - a telephony application embedded internet explorer in itself, and loaded some specially formatted webpages.
In the webpage there was this:
Call John Smith
Normally this would be a broken URL, but when the user clicked on this link, the application containing the embedded IE got notified, and proceeded to execute it's own custom code to dial the number from the URL.
You could get your VB guy to write an application which basically just wraps IE, and has handlers for executing applications. You could then code normal webpages with links to just open applications, and the VB app would launch them. This allows you to write your own security stuff (like, only launch applications in a preset list, or so on) into the VB app, and because VB is launching them, not IE, none of the IE security issues will be involved.
The second way is with browser plug-ins.
For example, skype comes with a Firefox plug-in, which looks for phone-numbers in web-pages, and attaches special links to them. When you click on these links it invokes skype - you could conceivably do something similar for launching your citrix apps.
You'd then be tied to firefox though. Writing plugins for IE is much harder than for FF, I wouldn't go down that path unless forced to.