So without further ado:

1. Option to not send attachments to cc’d recipients (on a per message basis).

Sometimes I want to send a fairly large attachment to one person and let other people know that I have sent it.  For example, if I want to send a response to a person who wants a big document from anyone on a DL.  I don’t want to send the document to the entire DL but I want to let the DL know that I sent it (so the recipient doesn’t get the same attachment lots of times from other people).

2. Ability to directly edit the Outlook name cache (the type ahead feature in addressees). 

Prior to Office 2010, this was stored in a file called profilename.nk2, in Office 2010 the same information is held in a hidden message on the Exchange server.  For some reason I have a few names that never seem to make it into my type ahead file (bug?) I have to type them into the address line every time I need them.  It would be nice to pull up the list of all the names in my cache and edit or delete ones or even add new ones.

 3. Ability to customizable the audible bing based on rules.

For example, if it’s just to me or from a particular set of people use one tone, if not use a different one.  I get enough “semi-spam” (stuff that is not true spam, but of little relevance to me) that I don’t want to read immediately that causes the “bing”.  I would like to have Outlook not sound the tone for most messages, but alert me if I get something directed to me or from a certain group of people that I define.

4. Easily share Quickparts between users and between the Office applications.

Quickparts is a very cool feature first introduced in Office 2007.  I just wish there was an easy way to import and export Quickparts so that they can easily be shared between users.  Also, Quickparts are implemented slightly differently between the applications in the Office suite.  It would be nice to have the interface the same between the different applications.

5. Multiple select in the addressee type ahead.

For example, perhaps I want to send an email to my co-worker and friend “Jerry” at both his home and work addresses.  If I type “Jerry” both addresses are shown in the drop down but I can only pick one of the two.  If I want to add both, I have to type “Jerry” twice.  Ctrl+Click would be nice to allow me to pick both.

6. Ability to work with the contents of the addressees on a message.

I get some messages that literally have hundreds of recipients.  On an inbound message, the order they show up in the to: list is the order they were entered by the sender.  When I am trying to figure out if a particular person received the message, I have to scan the entire list looking for the person’s name.  Outlook gives me a scrollbar but I typically can only see 4 lines at a time.  How about an “expand to display all” feature and a re-sort alphabetically feature for the to: and cc: boxes.  I know I can cut and paste the contents of these boxes into a document or spreadsheet, but that is a PITA.

7. In Microsoft Word, ability to better control how the comment boxes work during a review session

I review a lot of documents and I often find the comment box feature unwieldy. For example, I would like to be able to place a comment box on a page and not point it to anything but Word only lets me add a comment box connected to a bit of highlighted text.  Another thing I would like to do is be able to change the color of a comment box.  That way I could call it out during a review session ("what do you think about my comment in the taupe colored comment box?").

8. In Microsoft Word, the ability to control the font menu.

The font menu got a whole lot better in Office 2007, but I can think of a few nice ideas to make it even better.  For example, there are lots of fonts on my computer that I would probably never use (Gigi for example).  It would be nice to have an option to right click to hide a font.  I would also like to be able to tear-off the font menu and keep it as a floating menu off to the side of my document so I can see the entire document while still seeing my font dropdown list.  This would be nice for PowerPoint too.

I would be interested in hearing about features you would like to see in Office 201x.

-bruce

 Reliability Monitor was a new feature in Windows Vista.  It is an easy way to assess how a particular computer is performing from a reliability standpoint.  It can also help you find the root cause of some types of problems.  In a nutshell it is a chronological graph of the reliability of a computer.  The X axis shows the date and the Y axis shows a reliability value between 1 and 10.  The closer the computer is to a 10, the more reliable the computer is.  When something bad happens (like an application hang) the reliability score takes a hit.  When the computer runs without an issue for a while the score begins to improve again.  In my experience, when a computer has a reliability score of seven or greater the computer is running reasonably well.  In the graphic below you can see that this computer is not meeting that standard (it's actually one of my lab machines that has always been a bit problematic).

To see the Reliability Monitor, type "reliability" in the Start menu search dialog box.

There are several ways that Reliability Monitor can help troubleshoot problems.  Users often can't pinpoint exactly how often or when their computer is having an issue.  How many times have you heard statements like "It's stuck all the time" or "It crashed a couple days ago and I wasn't doing anything on it".  With Reliability Monitor you can see how often a computer is actually having problems and even which applications may have caused the problem.  Note that the computer doesn't have to actually crash to change the reliability rating.  A good first step is to pull up Reliability Monitor and see if there is an obvious problem.

Some time ago I uncovered an issue at one of my larger customers by using the Reliability Monitor.  While I was demonstrating Reliability Monitor to some of their administrators I noticed that there were several informational events every day on the computer.  When I looked more closely I realized that there was a script running that was installing and uninstalling the same piece of software over and over.  The root cause was that an administrator had built a script that had an unintentional loop in it.  This particular script was running on several thousand computers and no doubt was impacting both computer performance and the network performance.

The Reliability Monitor is a powerful tool that used in conjunction with other tools like the Event Viewer can help you solve some of the problems you may encounter in a large enterprise deployment.

The second tool I want to highlight is called the Problem Step Recorder (psr.exe).  This tool records the steps that caused a particular problem and information about the system and creates a tidy little package of all the information.  For example, let's say that a user is encountering an issue with one of the Office suite applications.  Rather than trying to explain to a helpdesk person over the telephone what the problem is, she can use PSR to record the problems and send the file to the helpdesk person.  The tool records mouse clicks, menu selections, screen shots and version information and saves all this information into an MHT file (which opens with your browser).  Depending on how long the recorded session is the file will typically be 1 to 2 megabytes which is fairly easy to send via email to a support person.

This is part of the output of the PSR tool:

There are several other great tools built into Windows 7.  Some have been around for several iterations of Windows (msconfig and performance montior for example) and some are newer (system information).  I recommend that administrators take a look at these tools.  For the really challenging problems the free Microsoft Sysinternals tools are available too.

-bruce

A user would report that when they tried to log on they got a message that said "The User Profile Service Failed The Logon.  User Profile Could Not Be Loaded" or they got a dialog box near the end of the logon sequence like this:

If they got the first message, they were taken back to the logon prompt.  If they got the second message, the logon would complete, but none of their user settings would be loaded (they would have to reconfigure Outlook, reset their IE homepage, reset their background image etc.).  Rebooting the computer did not fix the problem.

This problem is particularly frustrating for users because it seems to have come out of the blue.

The user profile consists of a local directory (folder) on the hard drive and a collection of settings in the computer's registry.  The profile folder contains all of that user's files (everything in My Documents, My Pictures, My Videos, Desktop, Downloads etc.).  If you want to really ruin someone's day, delete this directory and note that all those files they have stored on their desktop are gone (everyone stores stuff on their desktop, right?).  These folders are usually stored in C:\Users (Windows Vista and Windows 7) or C:\Documents and Settings (Windows XP).  The contents of the profile folder are created the first time the user logs onto a computer by copying the default user profile folder and renaming it to match the username.

This problem is nearly always caused by a mismatch between the actual name/location of this folder and the name/location stored in the registry.

The first image below is part of the HKLM hive of the registry of my lab computer (click on the image to see a higher resolution picture).  Each of the keys on the left that begin with "S-1-5" correspond to a user.  The first three are profiles for system accounts.  The ones with all the digits after them are user accounts for users that have logged onto the system.

The path to this part of the registry is shown at the bottom of the graphic.

Notice that the ProfileImagePath value is set to "C:\Users\Brucelan".  This is as it should be, since that is the correct name and location for my profile folder.  If I renamed/moved/deleted that folder, Windows is still going to try to load that profile and will fail.

This next image shows another user's profile information on my computer.  This user is getting the "You have been logged on with a temporary profile" message.

Here is the directory structure on my computer where the profiles are stored:

Do you see the problem?

Windows thinks the profile folder is called "Wilber Post" but the real folder name is "Wilber Post1".  I changed the name of the folder to create the problem.  The next time Wilber Post logged on to the computer, Windows tried to load his profile (it thought it was going to be available at "C:\Users\Wilber Post").  Windows found no folder there so it created a temporary profile to allow the logon to continue.  Windows then appended .bak to the profile key that failed to load.  Every time that Wilber Post tries to logon, Windows will now load a new temporary profile with settings copied from the default user profile.

To fix the problem, log on as an administrator, launch regedit and change the ProfileImagePath value in the key that ends in ".bak" to match the actual profile folder name.  Alternatively, you can change the name of the profile to match the ProfileImagePath value in the key that ends in ".bak".  After you fix the mismatch, change the key name that does not have ".bak" in it by adding an extension such as ".old".  Then remove the ".bak" extension from the correct profile key.

 The next time the user logs on, the profile path will match and Windows will not create a temporary profile.

What if the profile folder was deleted from the C:\Users directory?  In this case, simply make a copy of the default user profile directory and rename it to the user's name (verify that it matches the ProfileImagePath in the registry).  You will have to remove the ".bak" extension as explained above too.

 There is one more scenario that you may encounter related to this problem.  What happens if you are the only administrator on the computer and you receive the dreaded "The User Profile Service Failed the Logon" message?  This problem can occur if the computer was not shutdown properly.  The problem is the same (Windows has added ".bak" to the name of the profile key).  In this case you can't logon so how do you fix the problem if you are the only administrator?  The answer is Windows Safe Mode.  When you use Safe Mode, the profile will not be loaded so you should be able to logon and launch regedit and remove the ".bak" extension.  To start the computer in Safe Mode, restart the computer and hold down the F8 key during the start up sequence.

So far I have skipped over how the mismatch problem occurs in the first place.  The most common scenario I have seen is untrained users/administrators who move/delete a profile folder in C:\Users.  At one customer, it was common for users to go on extended trips away for the office (six months or more).  One administrator there would helpfully delete profile folders for users that were away on individual computers to "clean up some space".  When the user returned, they would logon and get the temporary profile because the registry key for their account was still there but the profile folder was gone.  Once I showed the administrators how to properly remove a profile from a computer this problem didn't occur again.

The correct way to change\delete a profile is to use the control panel (System>Advanced System Settings>Users>Settings):

 I hope this helps anyone who may have run into this problem.

-bruce

The customer still reported that the Office 2010 install failed on a small number of their client workstations.  I asked the customer to verify that the machines that had failed had enough available disk space and that they were otherwise similar to the ones that did not have a problem.

Then I wanted to look at was what the installer logs had captured.  The logs are stored in the TEMP directory (type %temp% in the search or run dialog box in the Start menu).  The installer log I wanted to review is called setup###.log where the ### is the date the log was created.

The log is quite long and can be a real challenge to review, but it will often provide the clues to figuring out why the install failed.

I verified that the OS was supported:

This machine is running the 32bit version of Windows XP with service pack 3 which is supported.

The next thing I did was look through the log looking for an error and the resulting Office 2010 rollback event.  One easy way to quickly find the error is to search the log for the word "verbose".  The installer service will automatically switch the logging level from standard to verbose when it begins the rollback process.  You may find the word "verbose" a few times before the rollback, but this search should quickly take you to the right point in the log.  Here is what I found:

 Office 2010 was failing to install and generating an error code of 1603 and then rolling back the install.

An error code of 1603 is usually caused by one of a couple things:

1) failure to read from a file location

2) corruption in the WMI database

The first possible cause is often related to the computer's TEMP directory (%temp%).  Another possible problem location is the Microsoft Help directory (%appdata%\Microsoft Help).  I deleted all the files except the setup log from these two locations and also verified that the file permissions were OK (the local system account has to have full rights to these two locations).  I rebooted the computer and started the Office 2010 installer again.  Note:  I could have used the Procmon.exe tool from sysinternals to more deterministically see if these directories were the problem.  Twenty minutes later, I had another failure and the same 1603 error. Drat!

I decided to try repairing the WMI repository.  For Windows XP here is what I did (Vista and Windows 7 use different commands):

From the Start menu>run command line I typed: regdll32 wbemupgd, UpgradeRepository   Note: the spacing and case are important.

This command has no U/I and finishes instantly.  I then checked the log to see what happened.  The log is located at %windir%\system32\wbem\logs\setup.log.

I rebooted the computer and then started the Office 2010 installer.  This time the install completed without issue!

Again, using a tool like Process Monitor would have helped me solve this one even more quickly but considering I had invested all of 45 minutes into the troubleshooting I was pretty happy with solving this one as quickly as I did.

-bruce

During testing everything had gone well but after deploying to several hundred users they started getting sporadic reports that users couldn't download templates from the Office.com website.  Other users reported that they were having trouble accessing online help (also from the Office.com website).  The odd thing was that some users were having no issues and when we tested it on our own machines (running Office 2010) we had no issues. I had a couple of ideas on the possible causes that I wanted to investigate:

1) Perhaps we were seeing a DNS issue resolving the website Office.com.  Not particularly likely, but worth checking before we started digging for a deeper problem.

2) A group policy setting might be blocking Office.com.  This seemed like a reasonable scenario though the customer was confident that they didn't have any Office 2010 related policies in place.

3) A firewall or proxy was blocking access to Office.com. 

I started the investigation by using nslookup to see what IP address was returned by DNS for Office.com:

A quick whois search confirmed that those were owned by Microsoft so I was reasonably comfortable that DNS was not an issue here.  On to idea number two.

I know there are two group policy settings available for Office 2010 that can limit access to Office.com content:

Microsoft Office 2010\Tools | Options | General | Service Options...\Online Content Online >content options

and

Microsoft Office 2010\Miscellaneous >  Disable hyperlinks to web templates in File | New and task panes

Note: these two policies are only available if you load the appropriate ADMX and ADML files for Office 2010.

Because the users reported that they couldn't get to Office.com (not that the hyperlinks were disabled) I thought it unlikely this was the problem.  Because the customer also said they had not used any group policy settings for Office 2010 (yet) I decided that it was time to investigate idea #3.

I asked users what happened when they tried to navigate to the Office.com website with Internet Explorer.  They reported no problems.  Hmmm....

My next troubleshooting step was to use the Microsoft Sysinternals Process Monitor to dig a bit deeper.  Process Monitor (v2.96) is a free tool from Microsoft and is available on the internet at: https://technet.microsoft.com/en-us/sysinternals/bb896645

I began capturing data with Process Monitor on a computer that had the problem.  I then tried to open a template from Office.com.

Here is part of the capture (slightly edited to obscure the actual IP addresses):

A couple of things are immediately clear here.  First, the connection is being dropped.  Second, the other end is an internal (10.x.x.x) non-routable address.  Likely a proxy or firewall.  This is starting to look promising.

Proxy servers or firewalls have rule sets often with dozens of configurations.  For example, the firewall might specifically deny access to a particular website or only allow a particular protocol (like http) through.

The odd thing is that we could successfully get to Office.com using Internet Explorer.  One difference is that it was Microsoft Word that was trying to access Office.com rather than a browser.

I decided to use another free tool called Fiddler to look at the connection.  Fiddler is available at: https://www.fiddler2.com/fiddler2/  Fiddler allows me to inspect the details of an http connection.

Here is some of that capture:

Here is some of a Fiddler capture from when I use Internet Explorer 9 to go to Office.com:

One thing I noticed is that the user-agent string from Winword.exe is not the same as the user-agent string from IE9 (as expected).

A user-agent string is passed from a client application to a webserver.  The original intent was to alert a website to the type of browser being used (and by extension any features or limitations it has).  Because the client application can masquerade as some other application by sending an altered user-agent string (aka spoofing) the technology has very limited value from a security perspective.  Having said that, many enterprise customers have rules on their firewalls/proxies that check the user-agent string from the clients against an approved list.  If no match is found the connection is dropped.  The thinking is that while not especially secure, it  "keeps honest people honest".  You can read more about user agent strings at: https://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-agent-string-problems-and-alternatives.aspx

At this point, I thought there was a good possibility that the firewall had several rules allowing the approved browsers through, but did not have one for an application like Microsoft Word.  A quick check with the team that managed the firewalls confirmed my suspicion.

The fix to our problem was to ask the network team to add Winword.exe and the other Office applications including CLview.exe (the online help engine) to the allowed user-agent strings firewall rule set.

By the way, the reason not everyone was having the issue was that there was more than one enterprise firewall and some of them had the correct rules already in place.

And lastly, there is a terrific new book by Mark Russinovich and Aaron Margosis that covers Process Monitor (and the other Sysinternal tools): https://www.amazon.com/Windows-Sysinternals-Administrators-Reference-Russinovich/dp/073565672X .  I highly recommend it!

--bruce