This Tech-Tip is one of those "shake my head in wonder" blog entries. Microsoft has - apparently - whipped out BOTH of its trusty six-shooters, taken careful aim at BOTH its feet and pulled the triggers. . . .
Now, fair is fair, and Microsoft HAS been trying to be more sensitive to customers needs. This is made especially obvious in Office / Outlook 2010 - where there is a major paradigm shift in the way mail-files are handled on local machines.
To make it easier to migrate Outlook 2010 from machine to machine, Microsoft has decided to encapsulate a lot of the mail preferences in the user's e-mail, (.pst), file - instead of scattering them willy-nilly all over the user's system. You pick up the .pst file from the system you are migrating from, drop it onto the system you are migrating to, and Voila! 90% of the work is done.
Except for one teeny, tiny, little thing. . . . .
Certain mail-account metadata is now being captured in the .pst file too. And, usually, that would be a good thing - the .pst file contains not only your mail and preferences, but a record of what mail has been read from the server, etc. etc. etc. This way, when you start up Outlook on your new computer, you don't necessarily get twenty-thousand e-mails all over again.
But there is a small hiccup with this idea: Someone clever at Microsoft had the brilliant idea that no-one would ever dream of associating multiple mail accounts to a single mail, (.pst), file - right? And because absolutely NOBODY would be that stupid, there is no reason to store more than one mail account's data in the .pst file! Of course, if you DO have multiple mail accounts, the metadata that gets stored is the data from the last account accessed.
Unfortunately Outlook has allowed multiple mail accounts to be aggregated into a single .pst file for decades. They even support it by asking if you want to re-use a pre-existing mail file when you create the 2nd or 34th, mail account.
So, if you're sharing e-mail between two computers, (as I often do), I set the "master" computer to delete e-mails when read - but the "slave" computer is set to "leave messages on server" so that the master computer can - eventually - get them. This makes all my mail-file migrations one-way affairs, master-to-slave, so I don't accidentally obliterate my mail files if I screw this up.
The problem should now be obvious!
If we assume that I have three different e-mail accounts; "a", "b", and "c" - they all get frequent e-mails, and the slave machine is set to not delete them from the server, then we have a big problem. . . .
I launch Outlook 2010 on the slave machine, and it reads e-mail accounts a, b, and c; gathering new e-mails from each account. Since "c" was the LAST account read, the read list for "c" is preserved, while the lists for "a" and "b" are discarded when Outlook exits.
The next time I launch Outlook on this machine, it realizes that all the e-mail from "c" has been read, so it leaves that alone - but since it has NO CLUE about account "a" or "b" - it blithely re-reads all that mail again.
The next time Outlook starts, since "b" was last, it re-reads all of the "a" and "c" e-mails!
So, depending on which account "just happened" to get the last e-mail, you end up with a round-robin re-reading of every blasted e-mail on those servers - until they get deleted.
The TechNet forums discuss this - and Microsoft says that having more than one mail account associated with a single .pst file will cause this because of the "new" way Outlook 2010 associates mail-account metadata with the .pst file.
Sigh. . . . Out comes the 9mm Glock and they take aim at their feet. . . .
There's a whole host of complaints about this on the Office/Outlook forums - hopefully Microsoft will come up with a patch or fix for this REAL SOON.
Please?
What say ye?
Jim
Thursday, May 20, 2010
Thursday, May 6, 2010
A key is a key is a key is a key . . . . . .
This is one of those "Doh!" moments - when I've been made to feel like a total ass - and I'm almost ashamed to post this. However, if I stuck MY foot in MY mouth over this - it's an even money bet that someone else will too. Hence the post.
Scenario:
I'm installing a 64 bit copy of Windows Server 2008 on this wonderfully excellent Dell PowerEdge 2850 server that I picked up at the Trenton Computer Festival on the cheap. Excellent system, six wide/fast SCSI drives on a BUTT-KICKIN' hardware RAID card, Dual Xeon's, tons of memory, I'm ready to hunt BEAR with this rig!
So, I do the install. I enter the product key, answer all the questions, put it on my domain, and - so far - everything seems just peachy-keen wonderful. Of course, my TechNet supplied activation key slides in like a champ. That is, until I went to actually activate this beast!
I try to activate it and it pauses for a moment or two, then tells me the activation procedure failed.
Huh?!! Wahappened?!! These keys normally activate as smooth as a floor waxed with silicone oil!
OK, obviously a network glitch, or the activation server was having a tough time. So I try again. No good. Activation STILL fails.
At this point I'm really scratching my head, as these things normally activate like a champ.
Eventually I get around to looking at error messages, ("Doh!" #1: RTFM - Read The Fantastic error Messages), and it tells me that it can't find a Key Management Server on my network anywhere.
Now that really puzzles me because - as I've been told and read on TechNet - Key Management Servers are typically used in HUGE enterprises with ZILLIONS of machines to coordinate their own licensing since Microsoft really doesn't want to try to keep track of every computer owned by Toyota, G.M. or Hughes Aerospace.
OK, you win. Maybe Win 2008 Server wants a KMS server as a matter of principle, so I look it up. And I discover that unless I have a particularly special kind of Volume Licensing Agreement - I can't even LOOK at a Key Management Server, let alone install one.
At this point I'm totally stumped. I go to bed, vowing to get some shut-eye and maybe, just maybe, things will look brighter in the morning.
Several Days Later. . . . . .
I try activation again - and it fails. In fact, since I'm getting ready to run "dcpromo" on this machine to make it a domain controller, I check the event logs as I have learned through bitter experience that your event logs have to be spotlessly clean if you want a successful Active Directory Domain Controller promotion. The event logs are filled with "SLS" errors from System Licensing Service – “cannot activate”.
I read up on the Web, check TechNet, search Microsoft, and dig just about everywhere - only to discover that there seems to be NO ONE who has had a problem like this. Microsoft has no clue. TechNet has no clue. The usual Fountains Of Wisdom on the web have no clue.
I start thinking - could it be a bad key? No - the key was accepted when I entered it. I know if I enter a "bad" (mis-typed, or for the wrong product) key - the "enter your product key" dialog barfs and won't let you proceed further.
Then I think a little further:
Windows Server 2008 comes in a whole rainbow of flavors, sizes, configurations, and such - for every possible taste and budget. And they're all "Server 2008", but they all have different keys. Hmmmm. . . . What if I put in a 2008 R2 key by mistake? Or a Win 2008 with Hyper Server key instead of the key for 2008 without Hyper Server? Heck! I can't even remember WHAT key I put in! So, let me try something. . .
Right next to the "activate Windows" setting on the "Computer" property-sheet, there is a "change product key" link. I go to TechNet, re-open my key list, and re-copy the exact key for the 64-bit Win2k8 Server (Without Hyper Server) Standard Edition that I was using. I write it down very clearly and legibly, and I go back to the Win2k8 Server and re-enter the product key.
I carefully type in all the groups of letters and numbers and - with trepidation - click on "next" since this is a one-shot deal. If you try to change your product key and crap-out, your copy of Windows is locked down tighter than the Strategic Air Command's command post at Cheyenne Mountain!
Windows pauses, swirls the key around in the glass, sniffs the key's bouquet carefully, takes a small sip, and - with cocked head - ACTIVATES!
"Doh!" Moment #2: Obviously, if a key works when entered, but fails to activate later on, maybe it's the wrong 'naffing key!!
I was surprised. Normally, if you enter a key that doesn't match what you're installing, it stops you right there. Since this particular install DVD was a multi-level install, capable of installing everything from the bare-bones VW Beetle version of 2k8, all the way to the Testosterone Infused Maserati version of 2k8 - maybe the keys are handled differently. Or maybe it's just the way W2k8 Server works. Obviously if the key doesn't match what it thinks should match, it tries to find a Key Management Server to verify that everything is legit.
Beats me. Strange problem.
What say ye?
Jim
Scenario:
I'm installing a 64 bit copy of Windows Server 2008 on this wonderfully excellent Dell PowerEdge 2850 server that I picked up at the Trenton Computer Festival on the cheap. Excellent system, six wide/fast SCSI drives on a BUTT-KICKIN' hardware RAID card, Dual Xeon's, tons of memory, I'm ready to hunt BEAR with this rig!
So, I do the install. I enter the product key, answer all the questions, put it on my domain, and - so far - everything seems just peachy-keen wonderful. Of course, my TechNet supplied activation key slides in like a champ. That is, until I went to actually activate this beast!
I try to activate it and it pauses for a moment or two, then tells me the activation procedure failed.
Huh?!! Wahappened?!! These keys normally activate as smooth as a floor waxed with silicone oil!
OK, obviously a network glitch, or the activation server was having a tough time. So I try again. No good. Activation STILL fails.
At this point I'm really scratching my head, as these things normally activate like a champ.
Eventually I get around to looking at error messages, ("Doh!" #1: RTFM - Read The Fantastic error Messages), and it tells me that it can't find a Key Management Server on my network anywhere.
Now that really puzzles me because - as I've been told and read on TechNet - Key Management Servers are typically used in HUGE enterprises with ZILLIONS of machines to coordinate their own licensing since Microsoft really doesn't want to try to keep track of every computer owned by Toyota, G.M. or Hughes Aerospace.
OK, you win. Maybe Win 2008 Server wants a KMS server as a matter of principle, so I look it up. And I discover that unless I have a particularly special kind of Volume Licensing Agreement - I can't even LOOK at a Key Management Server, let alone install one.
At this point I'm totally stumped. I go to bed, vowing to get some shut-eye and maybe, just maybe, things will look brighter in the morning.
Several Days Later. . . . . .
I try activation again - and it fails. In fact, since I'm getting ready to run "dcpromo" on this machine to make it a domain controller, I check the event logs as I have learned through bitter experience that your event logs have to be spotlessly clean if you want a successful Active Directory Domain Controller promotion. The event logs are filled with "SLS" errors from System Licensing Service – “cannot activate”.
I read up on the Web, check TechNet, search Microsoft, and dig just about everywhere - only to discover that there seems to be NO ONE who has had a problem like this. Microsoft has no clue. TechNet has no clue. The usual Fountains Of Wisdom on the web have no clue.
I start thinking - could it be a bad key? No - the key was accepted when I entered it. I know if I enter a "bad" (mis-typed, or for the wrong product) key - the "enter your product key" dialog barfs and won't let you proceed further.
Then I think a little further:
Windows Server 2008 comes in a whole rainbow of flavors, sizes, configurations, and such - for every possible taste and budget. And they're all "Server 2008", but they all have different keys. Hmmmm. . . . What if I put in a 2008 R2 key by mistake? Or a Win 2008 with Hyper Server key instead of the key for 2008 without Hyper Server? Heck! I can't even remember WHAT key I put in! So, let me try something. . .
Right next to the "activate Windows" setting on the "Computer" property-sheet, there is a "change product key" link. I go to TechNet, re-open my key list, and re-copy the exact key for the 64-bit Win2k8 Server (Without Hyper Server) Standard Edition that I was using. I write it down very clearly and legibly, and I go back to the Win2k8 Server and re-enter the product key.
I carefully type in all the groups of letters and numbers and - with trepidation - click on "next" since this is a one-shot deal. If you try to change your product key and crap-out, your copy of Windows is locked down tighter than the Strategic Air Command's command post at Cheyenne Mountain!
Windows pauses, swirls the key around in the glass, sniffs the key's bouquet carefully, takes a small sip, and - with cocked head - ACTIVATES!
"Doh!" Moment #2: Obviously, if a key works when entered, but fails to activate later on, maybe it's the wrong 'naffing key!!
I was surprised. Normally, if you enter a key that doesn't match what you're installing, it stops you right there. Since this particular install DVD was a multi-level install, capable of installing everything from the bare-bones VW Beetle version of 2k8, all the way to the Testosterone Infused Maserati version of 2k8 - maybe the keys are handled differently. Or maybe it's just the way W2k8 Server works. Obviously if the key doesn't match what it thinks should match, it tries to find a Key Management Server to verify that everything is legit.
Beats me. Strange problem.
What say ye?
Jim
Thursday, April 1, 2010
Showdown at Tombstone
How to Resurrect An Active Directory
In a somewhat weird coincidence, it is interesting that in the week before Easter I should be writing about how to bring something back to life. . . .
Active Directory has a feature common to all complex databases that can be replicated from machine to machine - it implements a feature called "Tombstones"
Tombstones are a way of marking data that has been removed as "deleted" - without actually removing the data - so that the request to delete can spread to all other computers sharing this information. Then - after a period of time long enough for all computers to have heard about it, the tombstoned data is actually and physically deleted.
This is needed because it is very difficult for databases to replicate the absence of data - to make replication more efficient, the only thing that gets replicated is the actual data itself.
In Windows*, the default tombstone lifetime is two months - 60 days - which under normal conditions is plenty long. What this means is that if data has been unused for 60 days, it's automatically tombstoned, (marked for deletion), and after another 60 days, it's actually removed. Note that when data is tombstoned, it's physically removed to a special place in the Active Directory - and for all intents and purposes, it's gone forever. It's possible to "reanimate" a tombstoned object, but most of the characteristics of the object were stripped away when it was tombstoned, making "reanimation" a dicey proposition at best.
However - QA test environments are often used in ways that are much different from "normal conditions". My friend Andy, for example, has a special test domain using two computers as domain controllers - one parent and one child - with other computers connected to them. And it is not unusual for him to set this system up, perform a series of tests, and then need to tear that system down and restore the pristine network to do other testing on. And there are some very nifty tools that allow him to do this in a very painless manner.
Unfortunately - some of these tests can take several months to complete. Or he might get distracted by his boss to work on something More Important for a while. The result is that the next time he "restores" the two computers in the domain from his most recent pristine backup, it's been longer than 60 days. This results in the entire Active Directory tombstoning itself - in essence comitting ritual suicide - while he watches his network automagically reduce itself to a quivering lump of rubble. And once that happens, there is little else to do but manually re-create everything from scratch - again! - to restore the pristine non-tombstoned status to the Active Directory.
There is a solution!
There is a special parameter within the Active Directory itself that tells Active Directory how long to wait before clobbering things, called the "Tombstone Lifetime", and it can be set to values that are reasonable for your situation.
Here's an example showing the problem and how to work around it:
I recently needed to restore a server - and my most recent backup was six months old. If I just restore it and fire the computer up, it will destroy itself by tombstoning. I can reset the computer's clock, but as soon as it gets on the network and gets the correct time - I'm dead again.
What you will need:
1. A server running active directory.
2. The "resource kit" or "support tools" distributed with your version of the server. Don't use earlier or later tools, they won't work properly.
What I did:
1. I set the computer's clock to a date six months ago that was just a bit later than the date the backup was taken.
2. I restored the backup image.
3. I removed the computer from the network (by unplugging it)
4. I restarted the computer.
Once the computer came up, I logged in and waited for it to settle down.
5. In the support tools for this server there is a program called ADSI EDIT - that can be used to make changes to the Active Directory in a manner similar to what REGEDIT does to the Registry.
You invoke it by either typing in "adsiedit" from a command line, or by finding the adsiedit executable and double-clicking on it.
6. Once it opens, you have to navigate to the correct object:
(a) Configuration Container ---->
(b) CN=Configuration,DC=[your domain name],DC=com (or net or whatever) ------->
(c) CN=Services ------>
(d) CN=WindowsNT
7. Once you get to the WindowsNT container, you will notice on the right an object called "Directory Service" Right click on that object, and select "Properties"
8. Inside the property sheet for that object is a drop-down list of properties. (a LONG list of properties. . .) Select the property called "tombstonelifetime" and note what it is set to. By default, on my machine, it was blank. Change it to some value that is reasonable for you - I selected 360 - to represent 360 days, and then press "Set".
9. Click OK a few times to get all the way back out, and you're set!
10. You can now re-boot the box, catch it at the BIOS settings, reset the system clock to the correct date and time, and continue with your life unaffected by the tombstone lifetime setting.
What say ye?
Jim
* UPDATE (5/12/10)
This is actually true for the versions of Active Directory prior to Server 2003 - SP1. (See the TechNet article here.) Windows Server 2003 SP-1 and later versions of Windows Server have Tombstone Lifetimes extended to 180 days by default. This came about because Microsoft's many customers discovered that systems being built in one centeralized location, then shipped to distant branch offices - or built-to-spec abroad then shipped elsewhere, would end up Tombstoning themselves while in transit.
Active Directory has a feature common to all complex databases that can be replicated from machine to machine - it implements a feature called "Tombstones"
Tombstones are a way of marking data that has been removed as "deleted" - without actually removing the data - so that the request to delete can spread to all other computers sharing this information. Then - after a period of time long enough for all computers to have heard about it, the tombstoned data is actually and physically deleted.
This is needed because it is very difficult for databases to replicate the absence of data - to make replication more efficient, the only thing that gets replicated is the actual data itself.
In Windows*, the default tombstone lifetime is two months - 60 days - which under normal conditions is plenty long. What this means is that if data has been unused for 60 days, it's automatically tombstoned, (marked for deletion), and after another 60 days, it's actually removed. Note that when data is tombstoned, it's physically removed to a special place in the Active Directory - and for all intents and purposes, it's gone forever. It's possible to "reanimate" a tombstoned object, but most of the characteristics of the object were stripped away when it was tombstoned, making "reanimation" a dicey proposition at best.
However - QA test environments are often used in ways that are much different from "normal conditions". My friend Andy, for example, has a special test domain using two computers as domain controllers - one parent and one child - with other computers connected to them. And it is not unusual for him to set this system up, perform a series of tests, and then need to tear that system down and restore the pristine network to do other testing on. And there are some very nifty tools that allow him to do this in a very painless manner.
Unfortunately - some of these tests can take several months to complete. Or he might get distracted by his boss to work on something More Important for a while. The result is that the next time he "restores" the two computers in the domain from his most recent pristine backup, it's been longer than 60 days. This results in the entire Active Directory tombstoning itself - in essence comitting ritual suicide - while he watches his network automagically reduce itself to a quivering lump of rubble. And once that happens, there is little else to do but manually re-create everything from scratch - again! - to restore the pristine non-tombstoned status to the Active Directory.
There is a solution!
There is a special parameter within the Active Directory itself that tells Active Directory how long to wait before clobbering things, called the "Tombstone Lifetime", and it can be set to values that are reasonable for your situation.
Here's an example showing the problem and how to work around it:
I recently needed to restore a server - and my most recent backup was six months old. If I just restore it and fire the computer up, it will destroy itself by tombstoning. I can reset the computer's clock, but as soon as it gets on the network and gets the correct time - I'm dead again.
What you will need:
1. A server running active directory.
2. The "resource kit" or "support tools" distributed with your version of the server. Don't use earlier or later tools, they won't work properly.
What I did:
1. I set the computer's clock to a date six months ago that was just a bit later than the date the backup was taken.
2. I restored the backup image.
3. I removed the computer from the network (by unplugging it)
4. I restarted the computer.
Once the computer came up, I logged in and waited for it to settle down.
5. In the support tools for this server there is a program called ADSI EDIT - that can be used to make changes to the Active Directory in a manner similar to what REGEDIT does to the Registry.
You invoke it by either typing in "adsiedit" from a command line, or by finding the adsiedit executable and double-clicking on it.
6. Once it opens, you have to navigate to the correct object:
(a) Configuration Container ---->
(b) CN=Configuration,DC=[your domain name],DC=com (or net or whatever) ------->
(c) CN=Services ------>
(d) CN=WindowsNT
7. Once you get to the WindowsNT container, you will notice on the right an object called "Directory Service" Right click on that object, and select "Properties"
8. Inside the property sheet for that object is a drop-down list of properties. (a LONG list of properties. . .) Select the property called "tombstonelifetime" and note what it is set to. By default, on my machine, it was blank. Change it to some value that is reasonable for you - I selected 360 - to represent 360 days, and then press "Set".
9. Click OK a few times to get all the way back out, and you're set!
10. You can now re-boot the box, catch it at the BIOS settings, reset the system clock to the correct date and time, and continue with your life unaffected by the tombstone lifetime setting.
What say ye?
Jim
* UPDATE (5/12/10)
This is actually true for the versions of Active Directory prior to Server 2003 - SP1. (See the TechNet article here.) Windows Server 2003 SP-1 and later versions of Windows Server have Tombstone Lifetimes extended to 180 days by default. This came about because Microsoft's many customers discovered that systems being built in one centeralized location, then shipped to distant branch offices - or built-to-spec abroad then shipped elsewhere, would end up Tombstoning themselves while in transit.
Saturday, February 6, 2010
When Worlds Collide
Windows 7 and Driver Conflicts
Hello again!
By now, most everyone knows about Windows 7. You've either seen it, (and maybe messed with it a little bit), or you now have a machine that runs it.
Like it or not, it's here to stay.
Another thing that everyone knows about is that Windows 7 marks a major paradigm shift in their security model. And it's not just the 3rd-party application developers that are getting caught in the shift - Microsoft's own in-house products also fall into this trap.
I guess the take-away here is that, even if it's from Microsoft, don't necessarily believe what they say about Windows 7 Compatability.
Here's a case in point:
Hardware:
Fortunately for me, that crufty, ancient, el-cheepo $9 off of the bargin rack at Christmas Tree Shops, webcam worked like a champ! I only get 320x240 at about 3fps, but it's enough to get by. And what the hay, it's a crappy, crummy, low-budget web-cam.
Later on, I purchased the Phillips web-cam, and installed it on my Athlon x2 64 bit, dual-core laptop (running XP), with skype, and it worked like a champ there too.
Yesterday - wanting to get "up to the minute" with my video on my big desktop machine, I went out and planked-down Heafty Bucks for the latest-and-greatest Microsoft LifeCam Cinema. 16:9 aspect ratio, HD quality video, stunning detail, frame-rates that would make the networks jealous, etc. etc. etc. It promised the moon and the stars - AND the rocket-ship to get me there! Of course, the quid you pay for that pro-quo was a price tag closer to $100 than I'd really like, but - hey! - you want a Mercedes, you can't expect to pay for a Hyundai.
So. . . .
I bring it home, carry it lovingly downstairs into my "dungeon" where all the computer stuff lives, unpack it and proceed to install.
The install goes like a champ. Of course, I politely declined their generous offer to load my machine up with the latest Window Live Essentials and Silverlight, figuring I have enough crap-ware on this box as it is.
I launch the LifeCam application and play with the camera. I really can't do much better than 640x480 with my hardware and video card, but I play with it anyway. I test the video, the sound (it comes with a built-in mic.), the pan-and-tilt, etc. etc. etc.
Once I was satisfied that it worked, I closed LifeCam and launched Skype.
Skype immediately recognized the new camera and cautioned me that since it has a built-in mic, I would probably have to re-configure my audio settings to use it.
So - I do just that. I re-configure the audio and make a test call to verify it - and it's all Golden!
I then go look at the video. . . . . And all I see is a black screen. I fiddle with it. I try a couple of adjustments, I fiddle with it some more, and still no video.
An article on the web says that I may need to re-reconfigure certain audio settings if I have video problems. So I go back to the Audio settings to check it out. And! About five seconds later, Skype crashes.
Huh? Wahappened?
I re-launch Skype, look at the video - still gone - and go back to the audio again. Blammo! Skype dies. Apparently if I launch Skype 4.1 with this camera installed, go to the video settings page, and then go to the audio settings page, Skype crashes.
Skype's web site recommended an upgrade to Skype 4.2 Beta - so I upgrade and try again.
OK - now Skype does not crash when I go from Video to Audio - but still no video. And opening up the tools --> options dialog causes any call in progress to freeze solid.
Looking on the web, I discover that owners of the Phillips 1300 web-cam, as well as some Logitech web-cams were having the same troubles as those that owned the LifeCams by Microsoft. And - of course! - it's all Skype's fault for releasing such a piece of junk to an un-suspecting public.
After fighting with this until the wee-hours of the morning last night, and the weeeeeeeeeeeeeee-hours of the morning this morning, (before going to bed), I decided I'd had enough. Fuzz this!! I'm gonna yank that piece of GAGH! right outta there and ram it down someone's throat!!
(Later on, after some serious shut-eye, I try again.)
I disconnect the web-cam, un-install the drivers, make sure everything's cleaned up, and reboot.
I'm getting ready to re-install the crummy 'ole ViviCam's drivers when - just for the S's and Grins of it - I decide to plug in that blasted 'naffing LifeCam again. Without the included drivers. . . .
Baaa-BING! USB Hardware device recognized!
Baaa-BING! USB Imaging Device (Microsoft LifeCam Cinema 1393) recognized!
Baaa-BING! USB Digital Audio Interface Device (Microsoft LifeCam Cinema 1393) recognized!
(pregnant pause)
Baaa-BING!! Your Hardware is Installed and Ready To Use!!
Huh?!! (shaking my head - the instructions are very specific about NOT plugging the device in BEFORE installing the software. . . .)
I look in the device manager - and it's all there and it's all happy.
Acid Test: I launch Skype. I get the dialogs about my "new" webcam and needing to check the audio properties again, but this time not only does the audio work, but I have working video!!
Hmmmm. . . . Interesting. . . . . .
After placing a test call to a friend of mine (and chatting for about 30 min or so!), I shut down and remove the webcam. I restart and then plug in the Phillips webcam I have (which I have been told will NOT work with the drivers installed by a whole chorus of posters on the web), and wait. . . .
I get the familiar two-toned chime that Windows gives when it recognizes - and corrected configures! - a new USB device. Two or three chimes later, it's "installed and ready to use", just like the LifeCam. And it works in Skype just as well. Just to make sure, I call my friend back and spend about another hour or so chatting about stuff - and conviced that Skype won't crash no matter what I do to it (including opening tool and option windows), I hang up and ponder.
What I suspect is happening here is this:
Unlike earlier versions of Windows, and that includes Vista, Windows 7 has a lot of these device drivers built in as "native driver support" items. Just like XP with external USB hard drives and the USB thumb-drives - you plug 'em in and they just work.
Normally, when a manufacturer supplies an updated or enhanced version driver for a device - to enable special features like the HD resolution, for example, the internal drivers get disengaged for that device. This prevents two different drivers from trying to work with the same device, which is the fast boat to a crashed system. Or - if it does NOT disengage the native drivers, it adds a functionality layer to the device, working with the existing drivers that are already there.
In this case - what appears to be happening is that both Windows 7 *AND* the LifeCam/Phillips/Logitech (etc.) drivers install themselves, but do *NOT* disengage the native versions, resulting in a huge driver conflict reminicent of Windows 95, and a crash. Maybe a crashed app? Maybe a crashed box? According to the Skype Garage (forum) on Windows 7 and Skype - both can, and do, happen.
I guess that we've been lulled to sleep by how well Windows XP has worked with it's drivers and such, that the idea of a massive driver collision has faded from memory. We forget the primary maxim of computers and installations of stuff: If everything is working wonderfully, you then do something new, and then everything, (or certain things), go to hell - the first thing to do is to back out all the recent changes.
Also. Just because Microsoft says it works, doesn't mean it REALLY works. Not even with Windows!
What say ye?
Jim
By now, most everyone knows about Windows 7. You've either seen it, (and maybe messed with it a little bit), or you now have a machine that runs it.
Like it or not, it's here to stay.
Another thing that everyone knows about is that Windows 7 marks a major paradigm shift in their security model. And it's not just the 3rd-party application developers that are getting caught in the shift - Microsoft's own in-house products also fall into this trap.
I guess the take-away here is that, even if it's from Microsoft, don't necessarily believe what they say about Windows 7 Compatability.
Here's a case in point:
Hardware:
- My 2Ghz Athlon XP system with 2 gigs of RAM running Windows 7 Professional
- My NVIDIA 7800 series video card.
- A Microsoft LifeCam Cinema (their top end web-cam - for almost $100!)
- A Phillips WebCam SPC1300NC (a mid-line web-cam for about $40-$50)
- A Vivitar ViviCam 35 web-cam (a fairly old and crummy web-cam I bought for $9 somewhere)
- Microsoft's very own LifeCam software - version 3.1.0.something
- The supplied Phillips drivers for their web-cam
- The ViviCam 35 drivers that were not even thinking about Vista, let alone Windows 7!
- The latest release version of Skype (4.1)
Fortunately for me, that crufty, ancient, el-cheepo $9 off of the bargin rack at Christmas Tree Shops, webcam worked like a champ! I only get 320x240 at about 3fps, but it's enough to get by. And what the hay, it's a crappy, crummy, low-budget web-cam.
Later on, I purchased the Phillips web-cam, and installed it on my Athlon x2 64 bit, dual-core laptop (running XP), with skype, and it worked like a champ there too.
Yesterday - wanting to get "up to the minute" with my video on my big desktop machine, I went out and planked-down Heafty Bucks for the latest-and-greatest Microsoft LifeCam Cinema. 16:9 aspect ratio, HD quality video, stunning detail, frame-rates that would make the networks jealous, etc. etc. etc. It promised the moon and the stars - AND the rocket-ship to get me there! Of course, the quid you pay for that pro-quo was a price tag closer to $100 than I'd really like, but - hey! - you want a Mercedes, you can't expect to pay for a Hyundai.
So. . . .
I bring it home, carry it lovingly downstairs into my "dungeon" where all the computer stuff lives, unpack it and proceed to install.
The install goes like a champ. Of course, I politely declined their generous offer to load my machine up with the latest Window Live Essentials and Silverlight, figuring I have enough crap-ware on this box as it is.
I launch the LifeCam application and play with the camera. I really can't do much better than 640x480 with my hardware and video card, but I play with it anyway. I test the video, the sound (it comes with a built-in mic.), the pan-and-tilt, etc. etc. etc.
Once I was satisfied that it worked, I closed LifeCam and launched Skype.
Skype immediately recognized the new camera and cautioned me that since it has a built-in mic, I would probably have to re-configure my audio settings to use it.
So - I do just that. I re-configure the audio and make a test call to verify it - and it's all Golden!
I then go look at the video. . . . . And all I see is a black screen. I fiddle with it. I try a couple of adjustments, I fiddle with it some more, and still no video.
An article on the web says that I may need to re-reconfigure certain audio settings if I have video problems. So I go back to the Audio settings to check it out. And! About five seconds later, Skype crashes.
Huh? Wahappened?
I re-launch Skype, look at the video - still gone - and go back to the audio again. Blammo! Skype dies. Apparently if I launch Skype 4.1 with this camera installed, go to the video settings page, and then go to the audio settings page, Skype crashes.
Skype's web site recommended an upgrade to Skype 4.2 Beta - so I upgrade and try again.
OK - now Skype does not crash when I go from Video to Audio - but still no video. And opening up the tools --> options dialog causes any call in progress to freeze solid.
Looking on the web, I discover that owners of the Phillips 1300 web-cam, as well as some Logitech web-cams were having the same troubles as those that owned the LifeCams by Microsoft. And - of course! - it's all Skype's fault for releasing such a piece of junk to an un-suspecting public.
After fighting with this until the wee-hours of the morning last night, and the weeeeeeeeeeeeeee-hours of the morning this morning, (before going to bed), I decided I'd had enough. Fuzz this!! I'm gonna yank that piece of GAGH! right outta there and ram it down someone's throat!!
(Later on, after some serious shut-eye, I try again.)
I disconnect the web-cam, un-install the drivers, make sure everything's cleaned up, and reboot.
I'm getting ready to re-install the crummy 'ole ViviCam's drivers when - just for the S's and Grins of it - I decide to plug in that blasted 'naffing LifeCam again. Without the included drivers. . . .
Baaa-BING! USB Hardware device recognized!
Baaa-BING! USB Imaging Device (Microsoft LifeCam Cinema 1393) recognized!
Baaa-BING! USB Digital Audio Interface Device (Microsoft LifeCam Cinema 1393) recognized!
(pregnant pause)
Baaa-BING!! Your Hardware is Installed and Ready To Use!!
Huh?!! (shaking my head - the instructions are very specific about NOT plugging the device in BEFORE installing the software. . . .)
I look in the device manager - and it's all there and it's all happy.
Acid Test: I launch Skype. I get the dialogs about my "new" webcam and needing to check the audio properties again, but this time not only does the audio work, but I have working video!!
Hmmmm. . . . Interesting. . . . . .
After placing a test call to a friend of mine (and chatting for about 30 min or so!), I shut down and remove the webcam. I restart and then plug in the Phillips webcam I have (which I have been told will NOT work with the drivers installed by a whole chorus of posters on the web), and wait. . . .
I get the familiar two-toned chime that Windows gives when it recognizes - and corrected configures! - a new USB device. Two or three chimes later, it's "installed and ready to use", just like the LifeCam. And it works in Skype just as well. Just to make sure, I call my friend back and spend about another hour or so chatting about stuff - and conviced that Skype won't crash no matter what I do to it (including opening tool and option windows), I hang up and ponder.
What I suspect is happening here is this:
Unlike earlier versions of Windows, and that includes Vista, Windows 7 has a lot of these device drivers built in as "native driver support" items. Just like XP with external USB hard drives and the USB thumb-drives - you plug 'em in and they just work.
Normally, when a manufacturer supplies an updated or enhanced version driver for a device - to enable special features like the HD resolution, for example, the internal drivers get disengaged for that device. This prevents two different drivers from trying to work with the same device, which is the fast boat to a crashed system. Or - if it does NOT disengage the native drivers, it adds a functionality layer to the device, working with the existing drivers that are already there.
In this case - what appears to be happening is that both Windows 7 *AND* the LifeCam/Phillips/Logitech (etc.) drivers install themselves, but do *NOT* disengage the native versions, resulting in a huge driver conflict reminicent of Windows 95, and a crash. Maybe a crashed app? Maybe a crashed box? According to the Skype Garage (forum) on Windows 7 and Skype - both can, and do, happen.
I guess that we've been lulled to sleep by how well Windows XP has worked with it's drivers and such, that the idea of a massive driver collision has faded from memory. We forget the primary maxim of computers and installations of stuff: If everything is working wonderfully, you then do something new, and then everything, (or certain things), go to hell - the first thing to do is to back out all the recent changes.
Also. Just because Microsoft says it works, doesn't mean it REALLY works. Not even with Windows!
What say ye?
Jim
Subscribe to:
Posts (Atom)