Well, okay, so I don't know that the title of this post is strictly true: you may be able to run the Adobe Updater even if you're not logged into Windows as a user with administrative rights--but I don't know how you launch Adobe Updater other than from the Help menu of an Adobe product and the point I'm really making in this post is that if you aren't logged into Windows with administrative rights, you either won't have the menu option "Check for Updates" (this was the behavior I observed in Adobe Acrobat and Adobe Reader) or the menu option "Adobe [Product Name] Updates" will be "grayed out" and unavailable to be selected (this was the behavior I observed in Adobe ColdFusion Builder).

So the point is this: make sure you're logged into Windows with administrative rights if you want to update your Adobe products! If you find this same behavior on another operating system, please post a comment to let me know.

I'm posting this because when I searched to figure out what the problem was, I couldn't find anything; fortunately, it dawned on me what the issue was. But some keywords for search engine indexing are in order here: Adobe Check for Updates menu item not shown, Adobe Check for Updates menu item not available, Adobe Check for Updates menu item not there, Adobe Check for Updates menu item missing, cannot run Adobe Updater.

Some terms for indexing purposes: SharePoint broken images, SharePoint images broken, SharePoint won't load images, SharePoint images won't load, SharePoint not loading images, SharePoint images not loading, SharePoint red X images, SharePoint images red X.

Well, when I ran into this issue I searched like crazy for a solution and came up empty. I don't want that to happen to the next person who runs into the issue so hence this blog post.

Here's the scenario: I did a new installation of SharePoint Server 2007 on Windows Server 2008 R2. Incidentally, this process itself was a major pain in the butt, but I finally got it done--only to find that none of the standard images (those located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\IMAGES and mapped in IIS so they load from http://[server]/_layouts/images) would load due to 403 Forbidden errors.

Now, these 403 errors are not immediately obvious--all you see at first is that the images are broken (that is, they won't load: instead you see a "red X" in place of the images). When you dig, you figure out the actual URLs being requested are in http://[server]/_layouts/images and that these requests are resulting in 403 errors.

For purposes of search engine indexing (that is, so others affected can find this post), here's the exact text displayed in the browser when you make a direct request for one of these images:

As you may know, 403 errors are those that indicate that the requested file is present, you just can't get to it (the displayed message makes that pretty clear). So I knew I was dealing with a permissions issue--I just didn't know precisely what caused that issue. And to be honest, I never really figured it out. But what's important is that I did figure out--okay, stumble upon--a way to solve it: in IIS, for each SharePoint Web Site, there's a Virtual Directory for _layouts and inside of that is an Application for images; I simply deleted and recreated that Application for images and all was well. I had to do this for each SharePoint Web Site and in each case it fixed the problem so I am certain that this is reliably solves the issue.

UPDATE 2010-06-02: I just ran into a similar problem. I came back here to this blog post and followed my own instructions--only to find that it didn't work. The problem this time was that I could get to resources using http://127.0.0.1 but not using http://. Well, technically I could get to resources using http://, I just couldn't authenticate successfully. So how exactly did this cause broken images? Well, even when referencing a page itself as http://127.0.0.1, SharePoint has a penchant for using http:// for image URLs included in the page--and so the page itself would load fine but the images wouldn't because of the authentication issue. The problem turned out to be that I had misspelled "Administrator" as "Adminstrator" so watch out for stupid spelling mistakes causing you to waste lots of time! I don't have any reason to believe this had anything to do with the issue this blog post is about, but since it manifested similar symptoms, I thought it was worth including here.

I just plugged my iPhone into my MacBook Pro via USB and was immediately informed that there was a new version of the iPhone software available and I was asked if I wanted to install that software. I clicked yes and the process started. While it was doing its thing, I moved over into my Windows XP instance running in VMWare Fusion. Well, part of the process of updating the iPhone involved the iPhone restarting and when it restarted, because I was using VMWare Fusion, VMWare Fusion grabbed the USB connection and this completely hosed the iPhone. Let me be clear: it didn't just mess up the update, it hosed the iPhone--meaning it wouldn't work at all. It isn't that the iPhone connecting to the Windows XP instance in VMWare Fusion hoses the iPhone inherently; in fact, in a normal circumstance, connecting the iPhone to the Windows XP instance in VMWare Fusion would be no problem at all. What is a problem, however, is the iPhone losing the connection to iTunes in the middle of the update process.

So my only choice was to restore the iPhone to factory settings and from there to restore the phone's settings from a backup. I'm not sure that before beginning the update iTunes bothers to do a backup of your iPhone (if it doesn't, it sure should and I recommend that you do your own backup before letting iTunes do a software update), but in any case it seems I was able to restore from a recent enough backup that I didn't lose much, if anything. Because I'm using over-the-air Exchange synchronization, my most imporant data (Contacts, Calendar, Email) are not synced via iTunes so fortunately there was no risk of losing any of that data.

But even though in the end I lost little to nothing, the whole process of restoring is long and a rather big pain in the butt. So for that reason alone, I highly recommend avoiding it at all costs--and that means making sure the USB connection between your machine and your iPhone is not interrupted when you're updating the iPhone's software!

Incidentally, even after restoring from a backup, I had to completely re-do my settings for my Adobe Exchange account (I'm guessing that the certificate for the phone can't be backed up). Also, although my setting for syncing an image directory on the MacBook Pro to the iPhone was still present, the image in the directory (I only have 1 image in that directory) was not on the iPhone until I did another sync and, because I use that image as my Wallpaper, I had to reset my Wallpaper after I synced the image back to the iPhone.

UPDATE: although this post was originally written in regards to running Windows in VMWare Fusion, as pointed out by multiple kind people who have commented on this post, this information is also useful for those accessing Windows through means other than VMWare Fusion including Parallels and Remote Desktop. Accordingly, I have changed the title of the post to include Parallels and Remote Desktop.

I use a MacBook Pro and on it I run VMWare Fusion on top of which I run Windows XP. Normally, when Caps Lock is on in the Mac, it's on in the Windows XP instance and when Caps Lock is off in the Mac, it's off in the Windows XP instance. However, from time to time, on the Windows XP instance Caps Lock becomes "inverted"--that is, Caps Lock on the Windows XP instance is reversed from what it is on the Mac. So on the Mac, Caps Lock will be off and on the Windows XP instance, Caps Lock will be on. Or, the Mac Caps Lock will be on--and so will be the light on the Caps Lock key--yet the Windows XP instance Caps Lock will be off.

Okay, now that I've established the problem, I'll go ahead and explain the solution, then for those interested, I'll backtrack into the details.

UPDATE: there is, at least in VMWare Fusion 2.0, a simpler solution than I originally detailed in this blog post (that original solution and my explanation of the cause of the problem are still included below): go to the Virtual Machine menu in VMWare Fusion and choose Send Key ==> Caps Lock. You'll note while you're there that there are a number of other keys you can send as well; I discovered this whole capability tonight while looking around to try to find a way to send the Insert key (Insert had gotten toggled on in Internet Explorer and I wanted to toggle it back off) which I didn't know how to do directly because the MacBook Pro keyboard has no Insert key.

UPDATE: as pointed out by Bob in one of the Comments to this entry, another simple solution is to launch the On-screen Keyboard application (generally this can be done by choosing Start ==> All Programs ==> Accessories ==> Accessibility ==> On-screen Keyboard; as noted by DrFooMod2 in a comment below, you can also bring up the On-screen Keyboard by typing "osk" without the quotes in the Windows Run... box) and toggle Caps Lock by clicking on the virtual "lock" button in the application. The On-screen Keyboard application shows--and can change--the state of Caps Lock in the Windows XP instance without any regard to the state of Caps Lock on the Mac itself.

So here is the solution: in the Windows XP instance, open an application that can toggle Caps Lock (didn't know Windows apps could do such a thing? Surprise!) such as Microsoft Word and go into whatever context is required for the app to toggle Caps Lock (in Word, that means typing in a document). Make sure Caps Lock on the Mac is off; this will mean that Caps Lock in the Windows XP instance is on. Start typing normally (that is, as if Caps Lock in the Windows XP instance is off); if you try to type "Hello" what you'll get instead is "hELLO" but as soon as you hit the space bar, the app will "correct" what you typed to "Hello" and toggle the Windows XP instance Caps Lock off--and as a result, Caps Lock will be back in synch between the Mac and the Windows XP instance. :)

Why does this problem happen in the first place? You've probably figured at least part of that out already: when you use an app that can toggle the Windows XP Caps Lock and you have Caps Lock on but type in a way that the app thinks indicates Caps Lock is on unintentionally, it "helps" you by "correcting" what you typed and turning off Caps Lock on the Windows XP instance for you. This isn't necessarily a bad thing--in a standalone Windows XP instance. However, with consideration to the fact that in this case it causes the Windows XP instance to toggle its Caps Lock but doesn't do the same for the Mac such that the Windows XP Caps Lock and the Mac Caps Lock become out of synch, it's not good. And why doesn't the toggling of Caps Lock in the Mac instance cascade up to the Mac anyway? As well as I can tell, Mac applications do not have the ability to toggle Caps Lock on and off (side note: this makes complete sense when you note the difference between what Windows & Mac do when you press the shift key while Caps Lock is on: on Windows, it's sort of a "double negative" type of thing such that the result is a lowercase letter whereas on Mac, the result is still an uppercase letter--so then it wouldn't make sense for the app to toggle Caps Lock) which means that VMWare Fusion can't toggle Caps Lock on the Mac when it is toggled in the Windows instance (now, I'm not even sure that VMWare Fusion can detect Caps Lock being toggled in the Windows instance but if VWWare Fusion can't toggle it on the Mac then really it's a moot point whether or not it can detect it being toggled in the Windows instance).

One note of interest: the behavior here makes it clear that the Mac-VMWare Fusion-Windows XP instance communication isn't along the lines of "Caps Lock on" or "Caps Lock off" but rather "toggle Caps Lock." See, you'll note that I didn't indicate that to fix the problem you just have to hit the Caps Lock key on the Mac and it will get things back in synch--that would work if the communication were "Caps Lock on" or "Caps Lock off" but since it's just "toggle Caps Lock" all that happens is that the Caps Lock gets reversed the other way around!

UPDATE 2012-07-27: this blog post is 2 days shy of being 4 years old and it's still generating comments! One such comment below states "Here is a simple solution (work around) that worked for me for inverted caps lock (same for num lock). When you are on VM or NXClient press 'alt'+'ctl'+'del', then press the caps lock(same for num lock). Then press 'escape'. Hope this works." I haven't tried this but wanted to pull it up here in the blog post in case it's of help to you. Thanks for the tip, Partha.