Man, I love the new Office 2013 in every way except the user interface decisions.  It’s so fast and works so well, kudos to the team for continuing to add useful features on such an old product.

I can’t say the same for the user interface.  There are so many usability issues, I don’t know how this passed QA.  Let me vent some, as is what people do on blogs on the internets.

1.  No window borders.  While Windows 8 continues the trend for massively thick window borders on the desktop, Office decided it would ignore the Windows team and their silly user interface guidelines, and just do no borders at all.  Talk about two extremes!  Thick borders are a waste of screen real estate certainly, but no borders are even worse because then the content of the window just blends in with the window underneath (especially since Windows 8 has no drop shadows).  Try working on a spreadsheet in a non-maximized window with other stuff open underneath.  It sucks.

2.  Does not use the standard Windows window frame or chrome.  Okay, I get that they are trying to get rid of as much chrome as possible to go for a flat aesthetic.  But they basically just gave the middle finger to Windows’ own window style in the process.  In basically every version of Windows going back to 3.0, you can set the color of the window frames.  Office says you can have any color you want, as long as it’s light gray.  So even if all your other Windows apps have blue frames, Office will be light gray.  This is particularly awesome because in Windows 8, inactive window frames are also light gray.  So your Office window frames always look inactive.  Awesome job!  Oh, there is one cue you can use to see if the window frame is active.  The title bar text and window widgets are black instead of medium gray.

3.  Everything else is white or light gray.  No really, this is true!  I’m not exaggerating.  From the aforementioned window frames, to the backgrounds behind every list, frame, email, ribbon, or anything else. It’s all exactly the same or just a smidge darker or lighter.  You can change the theme if you want a slightly different look, but it barely changes anything.  They give you three options: white, light gray, and dark gray.  Dark gray is really more light gray and light gray is really more off-white, but ehh… semantics.

6.  No distinguishing feature for folders with unread items except a light blue “count” next to it.  In previous version of Outlook, folders with unread items were bold.  This really stuck out and made it easy to visually see where unread email might be for folders you set up rules to sort.  In 2013, you get light blue folder counts and absolutely no chrome, so it’s quite hard to see at a glance which folder has unread items.

5.  Different appointment colors.  Since forever, Outlook has used the following color schemes for appointments until Outlook 2013: white for “free” appointments, blue for “busy” appointments, and purple for “out of office” appointments.  In Outlook 2013 they use white for “free” appointments, purple for “busy” appointments, and purple for “out of office” appointments.  Wait…what?  Yes.  This is true!  Now, granted, the “busy” and “out of office” purples are a slightly different shade, but it’s not immediately obvious at a glance.  At least it’s not yet for me.  Why change this?  Just more example of the Apple-like attitude of usability be damned, THIS IS ART!

6.  On Windows 8, Outlook 2013 uses the new Windows 8 “toast” notification feature instead of the old school desktop notifications.  While it’s nice there is a toast feature built into Windows now, it’s just not as useful.  You can’t change the position of the notifications – it’s always in the upper right where window widgets are, so you can’t close/minimize a window until you dismiss the notifications or move the window.  And something I personally didn’t use, but there is a lot of angry posts in various Microsoft forums that there are no flag/reply/forward buttons on the notification.

And here’s an honorable mention that’s been around for as long as I can remember:

If you select some cells in Excel – maybe you are trying to highlight something important in a big document – and then you change focus to another window and Excel becomes inactive, the selected cells will stop being highlighted.  Why, Office team, why?  Was there a giant outcry at some point that the spreadsheet must be clean of highlighted cells when it’s not in focus?! 

One of my “tech on the side” SMB clients has three Targus USB 3.0 docks and three Dell laptops.  Two docks work on all the laptops.  One dock does not work on any laptop.  So the dock is bad, right?  Congratulations!  You too could be tech support!  Swap it out for a new one and let’s go have a beer.

Targus says no.  They would rather pay somebody to talk me to death on the phone trying completely stupid troubleshooting techniques that in no way possibly would solve this issue BECAUSE THE ISSUE IS HARDWARE rather than just swap me out a new unit.

Sure, I understand they want to make sure I’m on the latest firmware and have my drivers up-to-date.  I also understand running some diagnostic tools.  But when hour number three rolls around for a $150 product, you have to wonder, are we using our time wisely here?  I don’t think uninstalling random applications and reinstalling the same version of drivers (again) is going to help.  Especially since other docks, of the same make and model, work fine.  Call it a hunch!

I would highly recommend avoiding Targus at all costs.

The Windows Server 2008 and 2008 R2 Hyper-V management packs for OpsMgr (aka SCOM) have a bug in them where they discover Windows Server 2012 boxes with the Hyper-V role installed.  Hyper-V has a few logs which have changed between the two versions and when the 2008 MP tries to query the server, it fails because the logs no longer exist.  This generates the alert you see in the title of this post.

There are several monitors that can cause this behavior and numerous other blogs have covered how you can override the MP and exclude your 2012 servers.  This does work most of the time.  However, I had one stubborn server where I simply could not find the object that needed to be overridden. 

Finally, it dawned on me.  The only problem is that the MP can’t find the log.  Why not just create the log and forget about overriding these stupid management packs?

It turns out that it’s actually pretty simple to do this, but the documentation is not the best, especially if you are not a developer, as it’s all buried in MSDN.

The log it’s looking for is one of the new Event Tracing for Windows logs that appear under Applications and Service Logs in Event Viewer.  You can’t create these as easily as it was to create event sources for the application log.  Fortunately, once you figure it out, it’s not too bad.  You need to create a manifest file.  This defines how logging is done for your application (in our case, a non-existent application).  All we need to do is create a “channel” that has the same name as the old Hyper-V logs.  There’s a program that comes with the Windows SDK called ECManGen.exe that does all the heavy lifting.  That’s a big download, though, so if you don’t have it, just use my manifest below.

Once you create the manifest file that defines the target log, use wevtutil.exe (which comes with Windows, thankfully) to import the manifest.  That’s it.  The log is created.  We don’t actually need to populate the log, we just need it to exist.  So this is sufficient.

Here is the manifest file.  For organizational purposes, so that these dummy logs don’t show up under the Microsoft\Windows section (we don’t want to confuse them with the real Hyper-V logs), I place them under a section titled “CompatibilityWithOpsMgrMP.”  Feel free to change this.  It’s just a logical name and doesn’t affect how this works.

xml version="1.0"?>
<instrumentationManifest xsi:schemaLocation="http://schemas.microsoft.com/win/2004/08/events eventman.xsd" xmlns="http://schemas.microsoft.com/win/2004/08/events" xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:trace="http://schemas.microsoft.com/win/2004/08/events/trace">
  <instrumentation>
    <events>
      <provider name="Microsoft-CompatibilityWithOpsMgrMP-Hyper-V-Network" guid="{7103BFE7-D8FC-42B2-A82B-331A24ED2C93}" symbol="Microsoft_Windows_Hyper_V_Network">
        <channels>
          <channel name="Microsoft-Windows-Hyper-V-Network-Admin" chid="Admin" symbol="Admin" type="Admin" enabled="true">
          channel>
        channels>
      provider>
      <provider name="Microsoft-CompatibilityWithOpsMgrMP-Hyper-V-Image-Management-Service" guid="{E7748442-4EA4-40EB-9A4D-ED4D1AAFF5FC}" symbol="Microsoft_Windows_Hyper_V_Image_Management_Service">
        <channels>
          <channel name="Microsoft-Windows-Hyper-V-Image-Management-Service-Admin" chid="Admin" symbol="Admin" type="Admin" enabled="true">
          channel>
        channels>
      provider>
    events>
  instrumentation>
instrumentationManifest>

Save the above to a file called hyperv.man then type the following at the command prompt: wevtutil im hyperv.man

To uninstall it later, type: wevtutil um hyperv.man

Note: you need the manifest to uninstall it, so don’t delete that file.

After this, reset the status on the alerts, recalculate health, and you are done!

I renewed my Lync certificates recently and after applying them, response groups stopped working correctly.  Basically, a call would come in, the agent would attempt to answer it, and upon doing so the call would immediately disconnect.  The call would continue to ring and bounce between agents until the queue naturally timed out.

The strange thing is that the Lync logs showed nothing remarkable: no errors, no warnings.  I did a SIP trace on the Lync Logging Tool, with no luck.  On a whim, I restarted the Lync Server Response Group service and after doing that, response groups started working again!

Going back through the log, I can see where Lync complained about being unable to connect to the match maker service, with a yellow warning, about the time I changed the certificate.  There were no further errors or warnings.  After I restarted the service, I saw a flood of information messages about connecting to and updating things with the match maker service, so I’m guessing (truly, this is a guess) that might be the culprit.

Moral of the story: update Lync certificates after hours and then reboot (or at least restart all Lync services) to be safe.

It’s easy to do with PowerShell.

Get-SCOMAgent | foreach { $_.HostComputer.RecalculateMonitoringState() }

At work we standardized on Fortigate firewalls a while back because they are feature packed, easy to use, and reliable units at a very affordable price.   Compared to Juniper and Cisco, it was night and day. 

Recently, we purchased some new Fortigate 80C units for our internal firewall replacement and I decided it was time to dive into the FortiOS 5.0 since these were fresh installs.  As I was mapping out the virtual IPs to our back end servers, I ran into a strange issue.  The unit was telling me it ran into its virtual IP limit at 50.  In previous OS versions, that limit was 500.  Yes, you read that right: by upgrading to the new version of the OS, you have a ten-fold decrease in the number of virtual IPs you can map! 

I couldn’t believe that was true – it must have been a soft limit and I was missing something.  So I called support.  They didn’t think it was true either because they could see in the documents that it did, indeed, decrease from 500 to 50 for the latest version.  They suspected it might be a bug.  So I had them escalate it to senior engineer.  Here is their official response.

Hello,

Unfortunately, 50 VIPs is the maximum limit for the size of unit that you have. Due to the change in OS and the features
that are now provided in the device, the limits have been set so that the device is not overloaded and eventually causing it to
go into conserve mode. This has been confirmed by a senior engineer and unfortunately there are no work arounds to this issue.

Regards,

NAME REDACTED
Fortinet TAC Americas

What a load of BS!  A handful of new features necessitated reducing the maximum VIP count by an order of magnitude even if you aren’t using the new features?  Shenanigans!

The truth is that they are trying to force users to upgrade to their higher end (read: more expensive) models since they market the 80C more as a branch office type of unit, even though, spec-wise, it is more than capable of being a front end firewall for internet servers.  I don’t blame the engineers.  They made a fine product.  The problem is that some suit up the chain ran some actuaries and saw that people were buying the 80C instead of units that cost two to three times as much from Juniper and Cisco and they want a slice of that delicious pie.  I think it might backfire, though.

This sort of corporate behavior pisses me off so much that unless this is changed in the future, I can’t ever recommend Fortigate again.  Who knows when or if they’ll change other limits arbitrarily some day and you get screwed by an OS upgrade?

I didn’t ask, but I wonder what happens if somebody already had, say, 150 VIPs configured and they perform an upgrade?  Does it just truncate the last 100 and call it a day?

Meanwhile, I downgraded to FortiOS 4.0 MR3 and this should work just fine for our planned lifetime for this equipment.  Maybe SonicWall is in my future…