When are Domain Admins NOT Domain Admins?

I stumbled across some strange errors when using the UAC as a Non-Default Admin (NDA). When logged in as an NDA and not the Built-In Administrator Account (BIAA) I ran into permission issues with the User Access Control (UAC) turned on. It appeared as if the w08 box (and w08r2) could not enumerate Domain Admins membership then the UAC is turned on. Even when I gave Domain Admins Full Control of a folder (or a drive) it would not recognize membership therein.

More info (than you might want) on that at my entry here: http://www.myfriedmind.com/techBlog/2009/10/14/UACAndDomainAdminsPermissionsIssueOnWindows2008.aspx.

This is the follow up to that, after I got a hold of MSoft. I called in and even though it was the middle of the night for the gentleman on the other end of the line (he was in India) he was very coherent and helpful. Or perhaps, helpful is not the right word since I found the solution that Msoft suggests rather, ummm, absurd. This should not reflect on him at all, he was great, it is just the, ummm, solution that is whacky.

After some testing with me he did verify that I was right and that the issue was with the Domain Admins membership enumeration. He then did some research and located this article: http://technet.microsoft.com/en-us/library/cc772207(WS.10).aspx.

This lays out what is triggering the issue, how w08 (and Vista) handle Admin Approval Mode (AAM). Again, you can read my earlier post for more background if you want. Basically, Domain Admins, unlike ALL OTHER USERS, are given two tokens. They have the full access token (like everyone else) and a second access token referred to as the filtered access token. This filtered access token has the administrative powers removed. Explorer.exe (ie the root of all) is started with the filtered access token, and thus everything is started with it.

Think of it is as RUNAS in reverse. Rather than being a Domain Admin you are reduced to peon status. It is, in effect, kryptonite.

The solution that MSoft gave was very simple – do not use the Domain Admins account. At least for file and folder permissions. Create a TOTALLY NEW group and assign the people that you would normally have as Domain Admins in there. Then give THAT group the permissions that you want.

You know, that answer still makes me chuckle. What a stupid, stupid solution. Here's why

1. It does not actually do the AAM thing. It does not ask me for consent, credentials, whatever I have it set to. It just says NO when I try to access a folder. No discussion. So UAC is not actually doing its job here.
2. I can access the share of the drive or the folder if I do it via shared drives. It is only an issue if I am logged on directly to the box. I really get using UAC to prevent malicious software install, but to stop me from opening a folder??? So now I need to be the Domain Admins to log on to the server, but something completely different to access a folder.
3. It has no affect on the Built-In Administrator Account.

I already have a group that I want to use for file and folder permissions or sensitive areas. The Domain Admins. And with good reason, because they are the DOMAIN ADMINS!!!!!!!! Now I have to track two groups. All because the UAC will not play well with others.

Here is my solution –> Hey UAC! Buh-bye!!!!!

Note - this is tested on a Windows 2003 R2 domain.

Further note - I have corrected it a bit - specifically the problem applies ONLY to Domain Admins - see http://www.myfriedmind.com/techBlog/2009/10/20/UACAndDomainAdminsPermissionsIssueOrPocketFullOfKryptonite.aspx for more info.

A while ago I noticed something odd on my Windows 2008 clustered file server. When I tried to open the clustered drive that I was using to hold my shares  from the box while logged in as a non-default admin (hereafter referred to as NDA) I got a message stating “Access is denied”.

This only happened if I was logged into the box itself in the server room or via Remote Desktop. I could access the hidden share for that drive remotely with no problem. Also, if I logged on with the built-it administrator account (hereafter referred to as BIAA) I had no problem. Finally, if I disabled the User Access Control (UAC) I could access the drive with the NDA.

Originally I thought that this might be caused by it being clustered, but Symon Perriman from MSoft assured me that he had not heard of this. Then I thought it might be because storage we were using and the driver – EMC PowerPath. But I put off any further testing until I had time to work on a non-production box and to wait for W08R2 to see if that would make a difference.

First the good news – it does not have to do with clustering. Now the bad news – it might be a serious issue.

The basic issue is that the UAC, on both W08 and W08R2 appears to have issues enumerating membership for certain groups. What is especially unfortunate is that Domain Admins is one of those groups that it has trouble enumerating.

My Discovery of the Issue

When I created the new box to test I was initially unable to replicate the problem. It was not until I looked closer at the clustered drive on the original box that I realized that the problem had to do with permissions. Since the clustered drive would contain folders that would limit who would have access I had removed the “Users” group, leaving “CREATOR OWNER”, “SYSTEM”, “Administrators” (for that box) untouched. I then added “Domain Admins” with Full Control since this would be clustered and I did not want to rely on the “Administrators” of one of the nodes for perms. My plan was to create the shares, inherit from above, and add the appropriate security groups.

Unfortunately, with the UAC turned on I could no longer access the drive even though the account that I was using was a member of Domain Admins, albeit not the BIAA. I got a very strongly worded “NO”.

I replicated the permissions on my test box and discovered the same issue. I then added Everyone to the root of the drive with “Read” permissions and suddenly the NDA could access the drive.

By POE (process of elimination <g>) I determined that of the four permissions included in “Read” – “Traverse Folder / execute file”, “List folder / read data”, “Read attributes”, and “Read extended attributes” – I only needed the middle two – “List folder / read data” and “Read attributes”.

Hmm, I wondered if the issue could be that some special account was being used by the UAC to check for the drive. So I removed the “Everyone” group and added the NDA with those two specific perms. I could access the drive. So it appeared not to be an issue with a unique account, but more likely that the Domain Admins membership could not be enumerated. Maybe.

So I added an old Global Security group that the NDA belonged to (after removing the NDA) with the necessary perms. That worked. So I removed that, added an old Local Security group that the old Global security group belonged to. That worked.

I am stretching for possible causes. I can conceive of no reason why the Domain Admins membership could not be enumerated when other older groups have no issue, even when the NDA is a member of a member of a group. The only thing that strikes me is that all the old accounts I have used do not have spaces. Stretching, I know, but there has to be SOME reason.

I create two new Global Security groups – “PermTest” and “Perm Test”, one with a space one without. I add the NDA to each and try each of the, granting them the necessary perms. Neither one worked. So that blows that theory. Just to put a nail in the coffin I add “Domain Users” and that works. Further testing with Msoft and I catch that I have to Log OFF and BACK ON for this. Ooops. Those new accounts work, but Domain Admins still will not.

So far (when the UAC is turned on and accessing with the NDA):

Works

• Directly adding NDA
• Adding Everyone
• Adding Domain Users
• Adding Old Global Security groups containing NDA
• Adding Old Local Security groups containing old Global Security groups containing NDA
• Adding anny counter OTHER than Domain Admins

Does not work

• Domain Admins
• ?

I open up ADSIEdit to look at the properties of “Domain Admins” vs “Domain Users”, I specifically want to see when it says the whenCreated and the whenChanged attributes are. It turns out that although they both share the same whenCreated date, the “Domain Admins” whenChanged is more recent. Except that the old Global Security group containing the NDA has been changed more recently and that one works.

So that is a dead end.

And why does the default administrator account have no problem even with UAC turned on?

Verification by another forest

I want a totally isolated confirmation so I contact a buddy of mine down in Ohio (thanks Stuart) who is also running a w03 network with a w08 member server on it. He runs into the exact same problem. So the issue does not appear to be bad media or erroneous implementation, unless we both made the exact same mistakes.

Moving to subfolders

I move my study to subfolders. I create a subfolder on a local drive, remove Users, add Domain Admins and test that. I get this message “You don’t currently have permission to access this folder”. If I choose “Continue” it adds the NDA account with Full Control and lets me in.

A closer look at the UAC

It is past time now that we delve into the UAC which seems to be giving us such problems.

In the original w08 it was located in the Control Panel under “User Accounts” and you had two options there – on or off. In w08r2 it is still located in the Control Panel but it has now been moved to “System and Security” and now you have four options (see image).

Quick testing on w08r2 soon reveals that the only time that the NDA can access the drive via “Domain Admins” perms is when the UAC is all the way at the bottom (ie turned completely off).

What you may not know is that behind the scenes these apparently limited choices actually control ten different settings in the Local Security Policy. You can access your Local Security Policy by going to your “Administrative Tools”. Look under Local Policies, Security Options and at the bottom you will find the entries I am talking about.

First, let me draw your attention to the very top one – “Admin Approval Mode for the Built-in Administrative account”. This is the source of that odd exception – that the built-in administrative account can access the drive regardless of the UAC settings. This is set to Disabled and is ALWAYS set to Disabled regardless of the changes you make in the Control Panel. The only way to change it to Enabled is to change it here.

What will happen if it gets changed from Disabled to Enabled? Basically the built-in administrative account (BIAA) will be treated like any other administrative account (such as the NDA). See the “Explain tab”.

So, if your devious mind is like mine you instantly wonder if changing it to Enabled means that since the NDA cannot access the drive and since the BIAA is being treated like the NDA now, does that mean that the BIAA cannot access the drive? The answer is that, sure enough, the BIAA account CANNOT access the drive when it is treated like any other admin account and UAC is on. Yeah! I have succeeded in making things worse!

What does it mean that the BIAA is treated like any other administrator? How does the UAC determine how they are treated? For that I draw your attention to the third UAC entry in the Local Security Policy – named “Behavior of the elevation prompt for administrators in Admin Approval Mode”. This is one of the areas where w08 and w08r2 differ in their implementation of UAC. W08r2 does not add any more entries into the Local Security Policy, instead it adds three more options to this entry and adds one more to the subsequent (“Behavior of the elevation prompt for standard users”). See the image below.

So there are multiple ways that administrators can interact with the UAC when it is turned on. But what if the UAC is turned off? That affects the eighth choice –“Run all administrators in Admin Approval Mode”. Per the Explain below, disabling this disables Admin Approval mode, and hence (I believe) the entire UAC.

W08 and W08r2 Admin Approval Mode settings results

Regardless of what level I set the Admin Approval Mode to (three in w08, six in w08r2), including “Elevate without prompting”, I was unable to open a subfolder or a root drive that had the perms I have been talking about using the NDA account when UAC is on. The prompts where the same – denial on root drives, prompting to grant perms to the NDA on subfolders.

Only when the UAC is off w08 has no problem enumerating the NDA’s membership in Domain Admins.

What does this all mean?

It seems to me the simplest solutions are:

1. turn off the UAC
2. do not use an NDA to access the server (the above is an issue with file/folder perms, but it might affect other aspects as well)
3. do not rely on either Domain Admins for permissions. On second thought, do not rely on Domain Admins for ANYTHING.

Until this gets addressed by Msoft you are probably safest (ironically) in turning the UAC completely off on your w08 boxes. Not ideal, especially since the addition of “Prompt for consent for non-Windows binaries” helps remove some of the Clippy aspects of the UAC (see my thoughts on that here). Unfortunately the UAC has its tentacles in pretty much everything and who knows when this issue might trigger something more serious?

On a side note, some of you may be wondering why the UAC has that particular exception for the BIAA, especially as it is never turned off unless you do it via the Local Security policy. I cannot read the mind of the makers, but I suspect that it has to do with protection against elevated privileges. If you can restrict all NDAs (but not the BIAA) then if someone does hack your system on a regular user account and elevates themselves to an NDA they could STILL be restricted. It seems to me a logical way to guard against that.

Let me know what you think….

m

followup - http://www.myfriedmind.com/techBlog/2009/10/20/UACAndDomainAdminsPermissionsIssueOrPocketFullOfKryptonite.aspx

I checked the prerequisites for installing sp2 on w08 at this entry -> http://technet.microsoft.com/en-us/library/dd335038(WS.10).aspx and there is no mention that Internet Explorer 8 needs to be installed in order for w08 sp2 to be installed. And perhaps this is a quirk with Windows Updates, but on identitical w08 boxes (not r2) I am offered SP2 on one and not on the other.

What I AM offered on the other is the installation of IE8 for x64. It has already been installed on the first box. Note that it is simply called 'important' not 'critical'.

So I install IE 8 on the 2nd box and voila! Now I can install sp2.

If you have tried installing the Windows 2008 Failover clustering one of the nice things that MSoft provides out of the box is a Cluster Validator. Not merely does it allow a more robust set of options for hardware, but it runs through a basic checklist of necessary and suggested configurations so you do not have to.

However, you may run into the following error under "Validate IP Configuration" -> Found duplicate IP address blahblahblah on node blahblah adapter Local Area Connection *blah and node blahblah2 adapter Local Area Connection *blah.

The reason for this is what is called the Teredo Tunneling Pseudo-Interface (TTPI). Which, as you can intuitively tell from its name is used to tunnel IPv6 traffic over an IPv4 interface. It turns out that the TTPI gives IDENTICAL IPv6 addresses to all the servers. Since the IP address is going through a unique IPv4 already this is not a problem (and prevents it from bumping against a different IPv6). When you apply it to clustering, however, this is flagged as an issue.

The basic solution is to disable the TTPI. The method I use is very simple:

1. Open up Server Manager to get to your Device Manager and under View select "Show hidden devices". (It is hidden, in case that was not obvious).

2. The TTPI should magically appear.

3. Now right-click and select disabled. I suggest you do this on all nodes

And you are good to go.

If this STILL does not work, take a look at Symon Perriman's entry here -> http://blogs.msdn.com/clustering/archive/2008/07/26/8773796.aspx

Have fun clustering!!!

I encountered a user who was browsing to a webpage that locked up their computer. I kid you not, we had to do a hard reboot, no ctrl-alt-del anything. She was using IE 7 and there were no fancy-schmancy toolbars on there, but I took a looksee at her add-ons as I have found these to not merely be an issue on occasion but even to be where malware has secreted itself.

I noticed an add-on named "jqsiestartdetectorimpl" which referenced jqs_plugin.dll. That is the Sun Java quickstarter file.

Now one of the problems in the whole realm of computers is that with so much competition, vendors do not care if they break your computer as long as they are on top. Who cares if your computer is slower as long as our product launches a microsecond faster. So you end up with a thousand (okay, I exaggerate) little programs sucking up memory because they each are thinking about numero uno. And no, numero uno is NOT you.

So I disabled that add-on and voila!

Note that many of these do NOT need to run for your stuff to work beautifully. And in this case (and others I have run across) all they do is mess up the browser, and possibly freeze the computer.

One nice thing about IE 7 and 8 is that they have a "no add-ons" mode. You can get to it a few ways

1. Start/Run and type "iexplore.exe -extoff" (sans quotes). Note that you will need to reenable any add-ons that you want since this turns them all off.
2. From the Start menu, to into Accessories / System Tools / Internet Explorer (No Add-ons). This will only disable add-ons for the duration of this session.

Note that #2 is better for troubleshooting since it does not turn them off permanently.

Remember - malware likes to hide here, so keep an eye on these.

I was pondering the UAC (User Access Control) on Windows Server 2008 and Windows 7 (nobody talks about Vista anymore) and it occurred to me that the experience of interacting with it reminded me of another time. An annoying, apparently helpful attempt by Msoft that actually prevents you from doing work (see here). Suddenly it struck me - the return of 'Clippy'!!!

Now, first off, I can understand MSoft's implementing the UAC. After all, everyone knows that MSoft is so full of holes that it should if it were a cheese it would be swiss cheese. Everyone knows that, even if it is not necessarily true. So to convince everyone that they were secure they had to prevent users (that would be us) from doing stupid things. Like installing programs that should not be installed or changing setting that would render their computer unbootable. Because, of course, if a user does those things than the people REALLY at fault are not the users (heaven forfend) but MSoft!

To quote on of my favorite sayings - "calling something foolproof fails to take into account the ingenuity of fools."

They have to do this because we are so stupid as a race that an entire industry has sprung up to inform us of the obvious. Such as "do not put a gasoline can in a fire" or "ax blades are sharp" or (as in this picture) "this egg product contains eggs".

Still, there has to be some sort of happy medium. W08 only offers two options - on or off. W08R2 offers more (and I will make some notes on that in another blog) but I fear that in general MSoft has gone too far in the wrong direction. They are so concerned with protecting us that they are annoying us. And if something becomes annoying we generally stop doing it.

Goodbye Clippy. Goodbye UAC.

Do I have a solution? Of course not. Except to suggest that the UAC could be tweaked to be more specific. What I mean by that is simply that rather than trying to prevent you from doing EVERYTHING, it should only prevent the main crucial things. Perhaps it should not question you when you are installing programs but only when you are not installing them from an executable from a DVD or from your local drive.

Or perhaps the solution is that high-end users simply turn 'Clippy' off. He is annoying and YES I DO KNOW WHAT I AM DOING AND I WANT TO DO THAT!

At least, most of the time...

Part 1 - Introduction
Part 2 - Basic Example
Part 3 - Complex Example
Part 4 - Final Notes
Bonus - Ajax History and the Memento Pattern
Extra Bonus - Issues with Opera

I dedicate this blog to Tomi, who brought this issue to my attention. Without I would be blissfully unaware that my ajax examples did not work with Opera.

To make a long story short, the basic Ajax history points that are demonstrated starting in this blog entry and on the site here fail miserably when used by Opera, even the most recent v 10. It would go forward once and then fail on either the next history point or going backwards. It worked fine if history was not stored.

At first I thought that it might have to do with Validation, so I turned off Event Validation and ValidateRequests but no dice. I tried modifying the LoadScriptBeforeUI setting on the ScriptManager thinking that maybe Opera was attempting to access the controls before they were instantiated. No dice.

Looking at the "Error Console" in Opera gave this confusing information:

JavaScript - http://www.myfriedmind.com/ajaxexamples/AjaxSimplehistory.aspx
Unknown thread
Error:
name: Sys.WebForms.PageRequestManagerServerErrorException
message: Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 400
stacktrace:   Line 5 of linked script http://www.myfriedmind.com/ScriptResource.axd?d=Ca9Q30sQJzQkznL95cxsbDyIKgsvVPJZcb1rw8ROyNsMckgQG68w3ACHnEiANP
BR_VaW0NUFhahnNTwkTQZ39NfZ8sEeH0NKN9NzfqKtjhs1&t=40a63f28
    function(a,d,f){if(this._request===d.get_webRequest()){this._processingRequest=false;this._additionalInput=null;this._request=null}var e=this._get_eventHandlerList().getHandler("endRequest"),b=false;if(e){var c=new Sys.WebForms.EndRequestEventArgs(a,f?f.dataItems:{},d);e(this,c);b=c.get_errorHandled()}if(a&&!b)throw a}
.....

The key is that it was not returning the 200 that we all know and love, but a 400 status. Per this Msoft article (kb 247249) -

If the contents of a GET request are corrupt, then the server is unable to determine the URL or the host to which the GET request should be sent. IIS is unable to retrieve the host information from the GET request packet in order to look up the meta data for the custom error. This is by design. Errors that result from severely corrupted GET requests are not customizable.

Now I KNOW that they are not corrupt. It works perfectly fine with IE and Firefox. When I run it on Fiddler (http://www.fiddler2.com/) - my go-to tool for troubleshooting odd Ajax problems I do see the 400 returned. Note in the picture that the first three are for IE which work (all 200s) the second set of three is for opera - the final one being the 400 error.

When I look at the raw data of that entry it tells me that the response is that it is getting a Bad Request <Invalid URL> (see below). hmmmmm, should I trust it?

Hunting and pecking I find various entries dealing with Opera and its issues with Ajax, most of them from years ago. And then I discover this gem: http://www.webmasterworld.com/javascript/3195000.htm which has this notation near the end (italics mine)

opera has a rather annoying bug. This occurred in both 8 and 9: If the URL is exactly the same, the PHP file results are cached, and all the requests terminate as soon as the first result is returned. IE does the same, but I was able to fix it by spitting out a couple of "no-cache" headers. opera ignores these headers.

I fixed that by adding an "id=" parameter to the URL, which made each URL unique. This forced opera to stop caching.

Wha??? So I added a querystring to the end of my url (it does not matter what it is) and it worked! In other words http://www.myfriedmind.com/ajaxexamples/AjaxSimplehistory.aspx?x=y will work in Opera but http://www.myfriedmind.com/ajaxexamples/AjaxSimplehistory.aspx will not.

Now here is the odd part, and to display it I am going to direct you to a slight different simple ajax example I just whipped up -> http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx. I am also going to give you a behind the scenes look (via fiddler) as to what, exactly, Opera is 'requesting'. The main modification I did was to change the length of the text used for the history point (I am only going to store hour, minutes, seconds to expedite this) to make it shorter and easier to view.

Again http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx works for the first one and fails for the second.

First, let us look at what happens in IE per Fiddler (note that I only include the querystring here for comparison, this example works in IE without it).

• clicking on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y 
  Post /ajaxexamples/AjaxSimpleOpera.aspx
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=042004
• clicking on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042004 
  Post /ajaxexamples/AjaxSimpleOpera.aspx
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042006
• clicking on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042006  
  Post /ajaxexamples/AjaxSimpleOpera.aspx
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042007
• clicking on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042007
  Post /ajaxexamples/AjaxSimpleOpera.aspx
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042008

Now the Opera per Fiddler -

• Now adding a querystring on to the end - ex: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y works. But notice what is happening behind the scenes with each click
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041426
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041426
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041426
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041443
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041443
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y%23&&myTime=041426#&&myTime=041443
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041443
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041443
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y%23&&&myTime=041426%23&myTime=041443#&&myTime=041535
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=0414535
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=0414535
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y%23&&&&myTime=041426%23&myTime=041443%23&myTime=041535#&&myTime=041537
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041542

Okay, okay, there was a long time between clicks (I was pasting it over), but do you notice anything different between the two (pay attention to the POST that is done via Ajax)? Internet Explorer ALWAYS Posts to the same URL - it ignores the hash entry. Opera prepends the previous hash entry after encoding it for the url, and so it gets longer and longer.

What is really, really odd is that Opera keeps prepending EVEN WHEN YOU HIT THE BACK BUTTON! So moving back and forth in your ajax history means that you are getting a longer and longer request entry. If you want to see this, snag fiddler -> http://www.fiddler2.com and try it. Your POST request gets longer and longer due to the prepending, but the URL does not reflect this at all. This ALL happens under the covers.

I finally went into Opera and tried turning off ALL caching (disk and otherwise). No luck! And when I set it to pretend to be IE it threw an error on the history point setting, claiming it was not asynchronous. I even went into opera:config under User Prefs and set the "History Navigation Mode" to 1 per this article http://www.opera.com/support/kb/view/827/ to prevent what it calls "fast history navigation". Still no dice! I even set the Opera to "Always Reload Https In History" and then connected via https to the page and that failed as well.

So why does adding a query string work? I honestly don't know. But this might be a clue - when it succeeded the hash was passed as a query string variable in Opera. When it failed, no query string was passed at all. There are a number of posts all over the web that refer to Opera caching when it should not, so I suspect that that may indeed be the issue - Opera is caching the page regardless of what it is told. Only by including the query string can you force Opera to not do whatever it is doing.

So there appear to be three solutions

1. Don't use Ajax history for Opera unless you use a query string (it might work in systems other than .net, I have not tested this)
2. Get Opera to fix the issue (good luck!)
3. Make sure you have a querystring, even a nonsense one, if your users will be using Opera...

Happy coding!

----------

Further notes:

This article -> http://cfis.savagexi.com/2007/06/12/opera-ajax-and-bugs talks about an issue with Opera rejecting status codes other than 200. However that is probably not the issue since it should be returning a 200 code anyway. Just something to keep in mind.

Now I should note assuming that it was a caching issue I added a bunch of code to prevent caching - including the ones below:

Response.ClearHeaders();
Response.AppendHeader("Cache-Control", "no-cache");
Response.AppendHeader("Cache-Control", "private");
Response.AppendHeader("Cache-Control", "no-store");
Response.AppendHeader("Cache-Control", "must-revalidate");
Response.AppendHeader("Cache-Control", "max-stale=0"); 
Response.AppendHeader("Cache-Control", "post-check=0"); 
Response.AppendHeader("Cache-Control", "pre-check=0"); 
Response.AppendHeader("Pragma", "no-cache"); 
Response.AppendHeader("Keep-Alive", "timeout=3, max=993"); 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT");
Response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();

But again, the only thing that appears to resolve the issue is the inclusion of a query string.

For those of you just enter the IT 'biz, let me assure you that Hewlett Packard was once a great company. Good, reliable printers. Functional Drivers. Not the crap we are handed today. It is alwasy sad to see a reliable company start to tube and I can only hope that this is a quirk, but I once again ran into an issue with their drivers.

We are using their Universal Print Driver because they have not come out with the neccessary drivers for Windows 2008 for our printers (not to mention the issue with their bidirectional channel component) and came across a rather strange bug. Let us say that we are trying to print the following document from Word 2007 that has a watermark. It should look like this:

However, when printed from an XP machine we only get half the letters. It looks like this:

I verify that there are no correct drivers from HP (nope!) and then I try changing a setting - maybe "Send Truetype as Bitmap". Wow! Now we have the other letters, we just dropped most of the original ones that were showing.

So I roll back the driver from PCL6 (v 5.0) to PCL5 (v 5.0). And guess what. It works. PCL 5 works where PCL 6 does not.

A little (true) story. I was about to fly out of town so I took my wife's car into an oil-change place just to get that task done. While there the tech pointed out that the alternator belt was missing a tooth. Now I have changed more alternator belts in my life than you can shake a stick at, and I should know better than to have an oil-change place change my belts, but since I was in a hurry I figured to let them do it for me this time.

Oops.

When I get back I find out that it is squealing when you start the car. Hmm, maybe they need to tighten it. I take it back and they can't repair it. It works on tensioning pulleys in that car and they tell me they think that one of the pulleys is broken. So I take it to the dealer to fix. The rep sits down next me after they have loaded the car up and taken a look and says, "Well, it is kind of good news. The pulleys aren't broken, they simply put on the wrong belt - it is too large."

It seems to me that these "Universal" print drivers from HP fall into that category. What use is a functional engine if the belts that you put on it do not fit.

Come on, HP, spend some time on the belts. Please.