Must Have Administrative Rights on Windows to Run Adobe Updater

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.

403 Forbidden Error on SharePoint Images (Images Broken, Won't Load)

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:

The website declined to show this webpage
HTTP 403

Most likely causes:
• This website requires you to log in.

What you can try:
Go back to the previous page.

More information
This error (HTTP 403 Forbidden) means that Internet Explorer was able to connect to the website, but it does not have permission to view the webpage.

For more information about HTTP errors, see Help.

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.

Make Sure USB Connection Not Interrupted When Updating iPhone

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.

Fixing Inverted Caps Lock on VMWare Fusion, Parallels, or Remote Desktop

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.

Determining if a USB Flash Drive is USB 2.0

Well, I published this post for about 5 minutes, then realized it wasn't entirely accurate so I pulled it down so I could have some time to revise it. I was hoping (and frankly, thinking) no one had actually seen it--then I looked in my own blog reader and found out it had consumed my feed. Doh! Sorry to anyone else who got the feed with the original post and then couldn't even link out to the post because it was no longer live.

Yes, indeed it is true: I am posting to my blog. :)

If you're like me, you are given USB flash drives from time to time. Now, when you buy a USB flash drive, at least at retail here in the US, it comes in packaging that tells you if it supports USB 2.0. But when someone gives you a USB flash drive, it very often doesn't come with any packaging at all--and that leaves you wondering a) how big it is and b) whether or not it supports USB 2.0. Unfortunately, many of the USB flash drives that are giveaways do not supports USB 2.0 (I presume this is because USB 2.0 flash drives are more expensive to buy, and probably produce, than USB 1.1 flash drives and so giving away USB 1.1 flash drives therefore saves the givers money). But...some USB flash drives given away do support USB 2.0, so you can't just assume when you receive a flash drive that it doesn't support USB 2.0. What's it really matter, you may ask? Well, USB 2.0 is considerably faster than any previous USB edition. And to be brutally honest, the deal is that when someone gives you a slower USB flash drive and you're in the situation I'm in where you already have a couple of USB 2.0 flash drives, you want to know whether or not the flash drive you've been given is worth keeping or not.

So...how do you tell if a USB flash drive supports USB 2.0? I wish I knew! I've poked around on both Mac and Windows XP and I've searched extensively online and I can't find any method that will definitively provide that information. At this point, the best I have is that sometimes you can get at least an idea on Windows XP as follows:

  1. Connect your flash drive to one of your PC's USB 2.0 ports. If your PC doesn't have 2.0 ports there is good news: if you connect a USB 2.0 device to a USB 1.1 port, Windows XP will often (possibly always) present you with a message that says the device can perform faster if you connect it to a USB 2.0 port. Perhaps this is in fact the best way to ascertain on Windows XP whether or not a device supports USB 2.0.
  2. Open Device Manager. This can be accomplished by right-clicking My Computer on the desktop and selecting Properties to open System Properties, clicking on the Hardware tab, then clicking the Device Manager button.
  3. Expand the Disk Drives item.
  4. Take note of the name listed for your device: as you can see in the image below, the name may tell the tale: in the image, you'll see that one of my devices is called "USB 2.0 Flash Disk USB Device." Now, that name could be misleading; just having "USB 2.0" in the name may not guarantee that the device supports USB 2.0--but I'm thinking it's probably a pretty good guess that if "USB 2.0" is in the name then the device does indeed support USB 2.0. The problem, though, is that even if the inclusion of "USB 2.0" in a device name does definitively mean that a device supports USB 2.0, it appears that the lack of the inclusion of "USB 2.0" in a device name does not definitively mean that a device is not USB 2.0: I connected another of my USB flash drives that has USB 2.0 actually stamped on it and the description displayed was "Memorex TD Classic 003B USB Device"--nothing there about "USB 2.0." That said, I think sometimes the lack of "USB 2.0" in the name can be enlightening: in the image, you can see that there is a device called "USB Flash Disk Device;" in light of the fact that this description is so similar to the description of the other device, excepting the conspicuous absence of "2.0," I think it's safe to assume that device isn't USB 2.0--but ultimately, that's still an assumption. I later connected another of my USB flash drives and it was called "Generic Flash Disk USB Device"--I'm guessing that one too isn't USB 2.0, but again, that's only a guess.

In the end, this post isn't as helpful as I hoped it would be because I have not been able to provide a definitive methodology for determining whether or not a device supports USB 2.0. If you have insights on this subject, please take the time to post a comment.

BlogCFC was created by Raymond Camden. This blog is running version 5.9.002. Contact Blog Owner