Showdown at TombstoneHow 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.

When Worlds CollideWindows 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:

• 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)

Software:

• 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)

When I built up this Windows 7 box, one of the first applications I added was Skype 4.1 and the ViviCam web-cam because I use Skype a LOT - to associate with friends in far off places, and to communicate with the family members abroad.  Both Skype and the web-cam functionality are important to me and I would have been much less likely to stay with Windows 7 if this did not work.

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

Windows 7 / Windows Vista Virtual Store Bug

In previous blog postings here I have talked about Windows 7 - as compared to Vista and XP - and all-in-all, (IMHO), Windows 7 is a pretty slick operating system.

Not unlike other "new" operating system releases, there are - and will be - teething problems that will eventually be worked out.

There IS one issue that - though probably "by design" - is sufficiently evil that it borders on being a really nasty bug: Neither Vista nor Windows 7 refresh the Virtual Store's image of a file when the target file changes.

At this point you may be saying "Virtual Store"??! What the. . . .!!!

A little bit of an explanation is in order:

Vista was Microsoft's first real serious attempt to tighten up their security model and they did this in several different ways . . .

• They implemented the now infamous UAC - User Access Control, (or User Account Control depending on who you're listening to).
• They designated several important areas within the operating system as "protected" areas - you are unable to write to these areas without specially elevated privilege levels.
• However - to maintain backward compatibility with older programs written for XP - they allowed a special exception: If a non-privileged process attempted to access a privileged (protected) area, a write-enabled copy would be created that would be accessed as if it were the original.
• They way they accomplished this is by using a special directory called the Virtual Store.
• This directory is located at:
  C:\Users\[current user]\AppData\Local\VirtualStore
  and it contains an image (copy) of any protected items that were accessed by non-privileged processes.

The idea has merit. Older programs written for XP or before, that automatically assume that EVERYONE is an Administrator level user and write all over the system willy-nilly will be given access to the Virtual Store instead of the Real Application. Virii who wish to install themselves into the Program Files directory get side-tracked to the Virtual Store - or raise a UAC - instead of just sneaking in.

The Virtual Store operates according to some very simple rules:

• If a non-privileged application attempts access to a privileged area (C:\Program Files\MyApp, for example), a copy of the thing they tried to access is copied to the Virtual Store.
  Viz. It would be copied to:
  C:\Users\[current user]\AppData\Local\VirtualStore\Program Files\MyApp
  . . .and the application would be given access to the Virtual Store instead of the real program path.
• If a non-privileged application tries to access a protected area, AND there is already an image of the object requested in the Virtual Store - the application is automagically re-directed to the copy instead of the original. In other words, if C:\Users\[current user]\AppData\Local\VirtualStore\Program Files\MyApp already exists (in the Virtual Store), then any reference to C:\Program Files\MyApp will automatically be redirected to the copy in the Virtual Store - AND - as far as the executing process is concerned, it will actually appear to be executing out of the C:\Program Files\MyApp directory!
• Pivileged applications - running as true administrator equivalents via the UAC or by inheriting elevated privilege - always get access to the real file, not the copy in the Virtual Store.

 This is all well-and-good, but if you're paying attention, you will have noticed a subtle issue has crept into the system:

• If I publish a periodic (or bug fix) update to MyApp\. . . . the updater or .MSI file that does the updating will actually and truly write to the real Program Files folder.
• However, once the update is done and the non-privileged application starts to run again, it only sees the cached version of the file in the Virtual Store's folders.
  
  - AND -
  
  
• The presence of an updated version in the Real Folder does NOT trigger a refresh of the cached data in the Virtual Store! 

There's the problem. Stale data in the Virtual Store will cause your program to run amok, even after a patch or bug-fix has been installed.

The solution is simple:

• Never store data or user-generated configuration files in a protected area, such as Program Files.
• When the non-privileged application begins to run - before it does ANYTHING else - it should check the Virtual Store manually - via the explicit path - and see if there is a "MyApp" directory there.
• If there is a virtualized copy there, delete it.
• Installer software or .MSI updaters should follow the same rule when they begin running.

This will force Windows to update the Virtual Store so that when the non-privileged application runs - and accesses data in the Virtual Store - that it will always get the latest-and-greatest version.

Note that this workaround will also work on a legacy system running XP or earlier - since the path to the Virtual Store will NEVER exist on these earlier systems, the program's logic will simply skip past that and go on to launching the application.

What say ye?

Jim

How to migrate Outlook mail from XP to Windows 7

One of the issues that's sure to come up, now that Windows 7 is gaining traction, is how to take your Outlook settings, e-mails, and such-like and move them to a Windows 7 machine.

---

 In my own case - I have Outlook 2003 installed on Windows XP and I am building up a "new" machine with Windows 7 on it, so I needed to figure out how to migrate my stuff.

Also - I tend to swap computers back-and-forth.  For example, when I travel, I take a Compaq laptop with me, but I use my AthlonXP powered desktop when I'm at home.  So, I periodically "syncronize" (swap back-and-forth) the e-mail files between the two machines.

In XP the correspondence is relatively easy to follow, since most of the Outlook data is located in two places:

1. C:\Documents and Settings\[user name]\Application Data\Microsoft\
   
   There is an "Outlook" folder that you copy in its entirety to the new location.  This folder has stored settings specific to your e-mail stuff.
   
   There are also "Signature" and "Stationary" folders here as well, if you have pre-defined signatures or stationary you use.
   
   
   
2. C:\Documents and Settings\[user name]\Local Settings\Application Data\Microsoft\
   
   There is an "Outlook" folder that you also copy in it's entirety.  This folder actually contains your mail files and such.  Depending on how much e-mail you have, these files can get pretty darn big!
   
   
   
3. Certain other data about your e-mail - such as account information, logins, server preferences, etc. - are (supposedly) located somewhere in the Registry.  I haven't gone looking for them yet.  And to be perfectly honest, I'm not sure I want to just go cutting, hacking, and pasting from XP's Registry into Windows 7's Registry.  I'd really want to know a whole lot more about what I'm doing before I start that kind of Open Heart Surgery on a computer.

Note:

• I am talking about Outlook - not Outlook Express.
• I've never used Outlook Express, so I cannot comment on it.
  
  
• I'm talking about Outlook 2003.
• If you have Outlook 2007, I have heard rumors that it is essentially similar.  I haven't installed Outlook 2007 yet, so I can't speak directly to that from my own experience.
• If you have an older version of Outlook, you will have to first upgde to 2003 (or better) before you can even think of doing any of this stuff!
  
  
• I am talking about a personal installation of Outlook, using ISP provided mail servers - usually POP and/or SMTP mail servers.
• If you have Outlook set up to use an Exchange Server for your e-mail, you probably have a system administrator that should be helping you with this.  Migrating Exchange hosted e-mail is outside the scope of this article.  It's not difficult, it's just a totally different beast.
• Sysadmins:  The user's localized settings and .ost /.pst files might well be located in these same places, based on the installation's configuration.
  
  
• I am talking about a manual migration, dragging files and folders around "brute-force", so to speak.
• The good part about this is that it costs you absolutely nothing, whereas the payware migration software out there can hit you up for $60 or better.
• The bad part about this is that - bottom line - YOU own it.  At the risk of mangling a great line from Blazing Saddles:  "One false move, and the e-mail gets it!"  The bottom line here is that if you know enough to do this, you also know enough to not come crying to me if you accidentally clobber your e-mail.  Can YOU say "backups"?  Ahhh!  I KNEW you could!
• If you have a LOT of machines to migrate, (and if you have that many, you should really consider a centralized mail-store like Exchange), the payware solution might end up saving you money and grief in the long-run since they supposedly migrate everything - including registry settings, etc.
  
  
• You will have to have "show hidden files and folders" as well as "show hidden system files" enabled on both XP and Win-7 before you will see these paths. 

---

 Migrating Outlook from Windows XP to Windows-7 Executive Summary:

The basic folder-to-folder correspondence is as follows:

The XP folder:
C:\Documents and Settings\[user name]\Application Data\Microsoft\Outlook\ (as well as ..\Signatures\ and ..\Stationary\)

Is located in the Windows 7 folder:
C:\Users\[user name]\AppData\Roaming\Microsoft\Outlook\ (as well as ..\Signatures\ and ..\Stationary\)

==========

The XP folder:
C:\Documents and Settings\[user name]\Local Settings\Application Data\Microsoft\Outlook\ (where all the mail files reside)

Is located in the Windows 7 folder:
C:\Users\[user name]\AppData\Local\Microsoft\Outlook\

---

 How I accomplished the move:

1.  The first thing I did was to install Office 2003 (which included Outlook in my case) on the target Windows 7 machine.
   
   
2. Once the installation completed, I shut down the computer and attached the old "XP" drive as secondary.  You can attach it directly to the hard drive controller - (I have several drive-bays on my main machine for just this reason) - or you can attach it through a hard-drive-to-USB adapter.
   
   
3. Once you restart the machine and launch Outlook, you are prompted to set up an e-mail account. I set up a bogus@bogus.com "fake" account so that Outlook would build the appropriate directory structures.
1. I didn't set up a REAL account yet, because Outlook gets pretty darn agressive when it comes to sucking e-mail off your servers - and I wanted to get the "where to put it" set up first.
   
   
4. I then closed down Outlook and opened up File Explorer windows in Windows 7 - one for each drive.
   
   
5. I copied the
   
   C:\Documents and Settings\[user name]\Application Data\Microsoft\Outlook\ (as well as ..\Signatures\ and ..\Stationary\)
   
   folders off of the XP drive and placed them in the
   
   C:\Users\[user name]\AppData\Roaming\Microsoft\Outlook\ (as well as ..\Signatures\ and ..\Stationary\)
   
   folders on the Win-7 machine.
   
1. You will get some prompts to overwrite things - go ahead and let it.
   
   
6. I copied the
   
   C:\Documents and Settings\[user name]\Local Settings\Application Data\Microsoft\Outlook\
   
   folder off of the XP drive and placed it in the
   
   C:\Users\[user name]\AppData\Local\Microsoft\Outlook\
   
   folder on the Win-7 machine.
   
   
   
1. You will get some prompts to overwrite things - like Outlook.pst, or Desktop.ini - go ahead and let it overwrite.
2. Because you are moving your main mail files here, this copy may take a LONG time to complete.  Maybe even measured in hours.  Go get a cuppa coffee.  Read the paper.  Take a nice loooong walk outside.  You get the idea, right?
   
   
7. Once the copies are complete, shut down and disconnect the XP drive - just in case!
   
   
8. Restart the computer, and restart Outlook.
   
   
   
   You should notice that Outlook comes up with all your mail folders intact.  If this does *NOT* happen, stop right here and review your steps.  This has to be right before you can move on.  Hopefully you copied from XP to 7, and not vice-versa, as that will have clobbered the mail-files on the XP box.  This is why backups are so important!
   
   
   
9.  Now, you need to go to "Tools --> E-Mail Accounts" and begin to configure your actual e-mail accounts, both send and receive, just the way you had them before.  Passwords, server names, the works!  (This is the stuff in the Registry that we didn't hack with, remember?)
   
   
10. When you are setting up your e-mail account, or accounts if you have more than one, I usually go to the "More Settings" button to open up an advanced settings window, and then select the "Advanced" tab.  On this tab you will find the check-box "Leave e-mail on server", and check this box to enable that feature
1. I usually check "Leave e-mail on server" to "ON" when I'm testing a new e-mail client as a saftey precaution.  This way if I accidentally screw something up, I can always go back to the old client on the old machine and everything's still working just fine!

---

Caveats:

Because we did not even try to mess with Outlook's Registry settings - certain information and preferences does not automatically come across when the move is made.  However these things can be fixed-up rather quickly.

• In my case, I have a great many individual mail folders - and sub-folders! - along with a whole host of rules set up to automagically sort my e-mail upon arrival.
• Though the rules - and their associated folders - survived the migration, sometimes the correspondence between the folder within a rule - and the actual mail folder itself - gets un-linked.  Probably because of the big differences in paths between the two systems.
• What will happen is that you will generate Rule Errors complaining that it could not move the mail to the respective folder - and the affected e-mails will remain in your Inbox instead of being moved to the correct folder.
• To fix this, go to the  "Tools" menu, select "Rules and Alerts", and then on the "E-mail Rules" tab, select the rule that had the problem.  Double click on the underlined folder name Outlook could not find, (it may appear to be absolutely correct!), and re-select the corresponding mail folder from the list.  Click "OK" to close the rule and save changes.  Next click "Run Rules Now" along the top, select the rule you just edited, and run that rule on the Inbox.  All the offending e-mails should now get moved to the correct folder.
• Repeat this for any other rule errors encountered.
  
  
• The Outlook "reading" format will default back to the original screen layout.  In my case, I greatly prefer the "reading pane on the bottom" layout, so I go to "View" on the top menu bar, select "Reading Pane" about half-way down, and then check "Bottom".
  
  
• If you moved your Signatures folder, all your custom signatures will have made the move with you, but the associations between the signatures and your e-mails may not have.
• To fix this, go to "Tools" on the top menu bar, then select "Options" (all the way down at the bottom!), and then select the "Mail Format" tab.
• Down at the bottom of this tab are the fields where you set the signature for new mails as well as replies.  If you have more than one e-mail account, you have to select each one individually from the "Select signatures for account:" drop down, and set signature preferences for each one.
• Select "OK" to exit.
  
  
• You may notice that Outlook now starts out on the topmost, most global, folder view called "Today".  Usually people have Outlook configured to start with their Inbox showing, (or their Calendar, etc.) rather than the, (IMHO, totally useless), "Today" page.
• To fix this, if you have the "Tools" --> "Options" page still open, click on the "Other" tab, and then near the top click on the "Advanced Options" button.  Otherwise, navigate back to it, click on "Other" then "Advanced Options".
• At the very top of the Advanced Options page is a browse selector labeled "Startup in this folder:".  Click on "Browse" and select the Outlook folder you wish to open when you start Outlook.
• Click on the "OK" button twice and you're done!
  

What say ye?

Jim