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…

There are a great set of PowerShell cmdlets for Failover Clusters, but what if you just want some information about your Cluster Shared Volumes on a remote computer without installing those cmdlets?  There’s an easy way with WMI.

Get-WmiObject -Impersonation Impersonate -Authentication PacketPrivacy -ComputerName "SERVERNAME" -Namespace "root\MSCluster" -class "MSCluster_DiskPartition" | where {$_.VolumeLabel -eq "VOLUMENAME"} | select -first 1 | select -Expand FreeSpace

In the above snippet, change SERVERNAME to one of the cluster nodes and VOLUMENAME to the volume label of the CSV you want to examine.  Of course, you don’t have to select a single volume if you want information from all the cluster volumes.  I did it this way because I only wanted to look a the CSV and not the quorum drive.  The above returns a single integer representing the free space for use later on in my script.

The impersonation and authentication settings are required for remote access but not local access.

Adapt the above to suit your needs. :-)

I whipped up this script to quickly find the oldest and newest files in a folder with PowerShell because we have some archive folders that have millions of files and it can crash Windows Explorer.  Other scripts I’ve seen online use PowerShell’s Where-Object after doing a sort on the entire collection, but that’s inefficient because it requires sorting millions of file records, which is slow.  What I’m doing is using ForEach-Object to track the oldest and newest dates as I parse through the directory list in whatever order it comes to me.  It saves a lot of time and memory.  Enjoy!

$olddate = [DateTime]::MaxValue
$newdate = [DateTime]::MinValue
$oldfn = ""
$newfn = ""
$path = "."
get-childitem $path | ForEach-Object {
    if ($_.LastWriteTime -lt $olddate -and -not $_.PSIsContainer) {
        $oldfn = $_.Name
        $olddate = $_.LastWriteTime
    }
    if ($_.LastWriteTime -gt $newdate -and -not $_.PSIsContainer) {
        $newfn = $_.Name
        $newdate = $_.LastWriteTime
    }
}

$output = ""
if ($oldfn -ne "") { $output += "`nOldest: " + $olddate + " -- " + $oldfn }
if ($newfn -ne "") { $output += "`nNewest: " + $newdate + " -- " + $newfn }
if ($output -eq "") { $output += "`nFolder is empty." }
$output + "`n"

http://www.rollingstone.com/music/news/beastie-boys-co-founder-adam-yauch-dead-at-48-20120504

Microsoft, in their infinite wisdom, designed Lync in such a way that if members of two organizations deploy Lync and try to schedule meetings with each other, Lync will use federation in order negotiate authentication between the two domains.  This is great if you have a federated relationship with all your partners that you want to hold meetings with.  But what if you want to do ad hoc meetings with unauthenticated guests?  Microsoft gives you two choices.  One is to allow automatic discovery of federated partners, where the Lync servers will negotiate with each other based on published DNS and other settings, and the other is to log into the meeting using the Silverlight client.

There’s just one problem.

If you have the Lync desktop client on your PC and you try to visit an external meeting link, such as https://lync.contoso.com/meet/username/EJHFSN and you are not a part of the Contoso organization and you do not have federation set up or do not allow automatic discovery of federated partners, it will fail with a useless numeric error code that means absolutely nothing.  Since the desktop client does not allow you log on anonymously, it will never fallback to guest logon, even if the meeting organizer has it enabled for the meeting.

TechNet to the rescue!  All you have to do is append “sl=1” to the end of the query string of the URL, so that you visit https://lync.contoso.com/meet/username/EJHFSN?sl=1 and then it will force the Silverlight client, which will allow you to log on anonymously.  In this scenario, Lync meetings then behave basically like WebEx or GotoMeeting, where external participants need a browser plugin to connect to the meeting.  Perfect.  That’s exactly what I want.

Again, one problem.  Imagine trying to get your entire staff to always remember to append that to the meeting link when they set up external meetings.  Despite best efforts, it’s just not going to happen.  Your CFO has better things to do and she will forget, because that is human nature.  And, really, this is Microsoft’s shortsightedness here.  You can read my comment at the TechNet article linked above.

Thanks for the "?sl=1" trick. That did the trick for me. But explaining this to my users is going to be a pain. Imagine me in the CFO's office after months of extolling the virtues of Lync and how we even got rid of our WebEx subscription because, heck, Lync does meetings too! But suddenly, a meeting participant is also using Lync at his company but we have no federated relationship with each other, so when we click on each other's meeting links it just fails with a terrible numerical error. "I thought this thing could replace WebEx," the CFO bellows, scowling at me in disdain. "Oh, it can," I reply, "just make sure you modify every meeting invitation so that the URL has ?sl=1 at the end of it!" Yea, that will go over well.

Thankfully, there is a workaround.  And due to the way Lync is designed, it’s really not difficult to set up.

When you set up your Lync websites, it creates an internal and external site.  The external site by default uses the non-standard ports 8080 and 4443.  The Lync best practice is to use a Reverse Proxy or firewall port forwarding rules to send traffic destined for the normal web ports to the Lync alternate ports.  Your internal users, on the other hand, use ports 80 and 443 as normal, directly communicating with the Lync server.

Reverse proxies can also be set up to modify URLs before the connection is sent to the backend.  This is known as URL Rewriting.  In this case, you want a URL rewrite rule that will modify connections to /meet/ such that ?sl=1 is always added to the end.  I found from trial and error that you get the best results by only modifying the /meet/ part of the above URL (assuming you are using Simple URLs like that).  So I set up my topology so that 8080 and 4443 were exposed directly to the outside so I have an option to bypass the reverse proxy once the connection is established.  This is all completely secure and transparent to the end user.  We’re not bypassing the firewall, just the reverse proxy’s URL rewriting when it is not needed.

So the final topology looks like this.  (The Lync Front End is either your Edge server or your single server depending on the size of your deployment.)

From outside my firewall, ports 80, 443, 8080, and 4443 are all open.  If you connect to 80 or 443, you are sent to the reverse proxy.  If you go to 8080 or 4443, you are sent directly to Lync.

To prepare Lync for this configuration, I first edited the topology so that the published ports are assigned the same as the internal (8080 and 4443) as this will allow us to bypass the reverse proxy when it is not needed.

Whenever you publish your topology, remember to rerun the Lync setup wizard.

The reverse proxy can be easily created using IIS.  In fact, you can set it up on your Lync edge server if you want.  It depends on your workload.  For the purposes of this post, we’ll assume you are setting it up on the same server.   Note: Lync will stop any non-Lync website in IIS whenever you publish your topology and rerun setup, so be prepared for this!

In order to configure the reverse proxy, you need to install the Application Request Routing and URL Rewrite extensions for IIS.  These both should already be installed if you are using your Lync server.

Enable the Application Request Routing.  This is done at the server level.  Click on your IIS server in the IIS manager, double click Application Request Routing Cache, then click on Server Proxy Settings.  Check Enable proxy and keep everything else at defaults.

Create a new website.  Give it a folder path that is not shared with any other site (i.e., don’t reuse C:\Inetpub\wwwroot).  The bindings should be whatever the external IP address is mapped to through your firewall.  Bind HTTP and HTTPS on the default ports.  Make sure you use a different internal IP address than your Lync internal website so there isn’t a collision.  You don’t want internal users going through the reverse proxy.

Go into the site’s URL Rewrite section and create a dummy rule.  We are going to overwrite this later, so it doesn’t matter what it is.  We just want to create a web.config that we can edit by hand.

Edit the web.config “rules” section for the reverse proxy site.  Now here is where the fun begins.  We are going to modify any request that goes to /meet/ so that it has sl=1 at the end.  I created a rule for both HTTP and HTTPS since I am using default Lync ports (non-standard web ports).  There is also a condition that if the query string already contains sl=, it will not modify it.  Underneath the /meet/ rewrites are the default rules that just pass the request through unmodified to the correct ports.  Obviously, URLs, RegEx, ports, and so on, will all need to be modified to match your environment.

<rules>
    <rule name="ReverseProxyInboundRule1" stopProcessing="true">
        <match url="^meet/(.*)" />
        <conditions>
            <add input="{QUERY_STRING}" pattern="(.*)sl=(.*)" negate="true" />
            <add input="{CACHE_URL}" pattern="^(https)://" />
        </conditions>
        <action type="Rewrite" url="{C:1}://lync.contoso.com:4443/{R:0}?sl=1&{QUERY_STRING}" appendQueryString="false" logRewrittenUrl="true" />
    </rule>
    <rule name="ReverseProxyInboundRule2" stopProcessing="true">
        <match url="^meet/(.*)" />
        <conditions>
            <add input="{QUERY_STRING}" pattern="(.*)sl=(.*)" negate="true" />
            <add input="{CACHE_URL}" pattern="^(http)://" />
        </conditions>
        <action type="Rewrite" url="{C:1}://lync.contoso.com:8080/{R:0}?sl=1&{QUERY_STRING}" appendQueryString="false" logRewrittenUrl="true" />
    </rule>
    <rule name="ReverseProxyInboundRule3" stopProcessing="true">
        <match url="(.*)" />
        <conditions>
            <add input="{CACHE_URL}" pattern="^(https)://" />
        </conditions>
        <action type="Rewrite" url="{C:1}://lync.contoso.com:4443/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
    </rule>
    <rule name="ReverseProxyInboundRule4" stopProcessing="true">
        <match url="(.*)" />
        <conditions>
            <add input="{CACHE_URL}" pattern="^(http)://" />
        </conditions>
        <action type="Rewrite" url="{C:1}://lync.contoso.com:8080/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
    </rule>
</rules>

If you attempt to connect to a meeting externally now, this is what happens.

1. Browser initiates connection to https://lync.contoso.com/meet/username/EJHFSN.
2. Reverse Proxy receives the request, adds sl=1 to the query string, and passes the request to the external Lync website at https://lync.contoso.com:4443/meet/username/EJHFSN?sl=1.
3. Lync server replies and tells the browser to load the Silverlight Lync client which then attempts to connect directly to the lync web services (bypassing the Reverse Proxy) at https://pool1.lync.contoso.com:4443/Reach/Client/WebPages/ReachClient.aspx.
4. The external user can join as an anonymous guest, or log on using the domain credentials of the organizer’s meeting, if they have that.  The desktop Lync client will never launch!

Hopefully in the future Microsoft will fix the desktop client to allow it to log on anonymously to external meetings and also give us a checkbox in the Lync Server Control Panel that allows us to force all external connections to the Silverlight client (for legacy organizations that might connect to ours).

I just finished watching the Elfen Lied anime, which is based on a fairly long running manga.  The anime was only 13 episodes long, with one 30 minute OVA being produced afterwards.  This anime has been out for a while, so I’m a bit late to the party in commenting on it, but it was such a shocking series, I felt it deserved its own post.

The anime opens with Lucy, a young girl with horns, pink hair, and strange powers, fully nude walking through a building that looks like a cross between a bomb shelter and insane asylum.  As she walks down the hallways, she is ripping guards and scientists to shreds using powers that are explained later in the series.  Blood, bones, guts, and organs splatter everywhere.  This scene sets the tone for the rest of the anime.  I’ve read critics of the series decry this portrayal as over-the-top and gratuitous or simply sex and violence fan service. 

If that’s all you watch and then turn it off, I would agree.  But as you continue to watch the first episode, the mystery of what Lucy is, what that facility she was in is, and how that all relates to the college aged teens she meets who take her in to help her, is absolutely engrossing.  That scene is not the end of the extreme violence and nudity.

As the first few episodes progress, you begin to see the reason behind the over-the-top approach to this anime.  Nearly all of the characters are absolutely tortured.  Without giving away too much of the plot, you have one character who witnessed his sister and father brutally murdered before his eyes at a young age, another who was sexually molested by her step father with her mother accusing her of lying and eventually abandoning her, one whose limbs are mutilated and is left for dead, and several who are tortured repeatedly in gruesome and inhumane ways by authority figures.  The nudity and blood is simply a way to reinforce and help push the sort of emotional twistedness of the extreme horrors the characters have been through.

Nudity in most movies or series is usually a precursor to a love scene.  In this anime it’s more closely tied to something bad, usually quite violent, happening to a character.  It’s actually quite a brilliant mind screw and a good way to get you to empathize with the torture the character is experiencing.

So, yea, not for kids, this one.

My only complaint is that while the first four episodes and last four episodes were strong, the middle was very slow.  This is a weird thing since anime is based on a rather long running manga.  You would think they had plenty of material to work with, but it’s almost like the producers and writers just lost their way in the middle.  The same fights and arguments were fought and argued again and again.  Nothing new really happened.  And the conversations just sounded very forced.  I’m not sure why this happened.  Maybe it was a brief reprieve before the torture started again?  lol.  Also, without giving away the ending, I will just say that it had a satisfying conclusion, but ended with the typical amount of loose ends that most anime series end up having. 

The OVA was apparently never released in the USA, but it’s easy to find on the internet with subtitles.  It takes place in the middle of the series and is rather light hearted compared to the series and answers a few questions that were not otherwise resolved.  Honestly, they should have cut the middle four episodes down to two and added the plot of the OVA into the middle and the pacing would have been a lot better.

So, if you can tolerate watching something that will mess with your emotions and shock you with gruesome violence and gratuitous nudity, this is an anime I have to highly recommend.  The series is on NetFlix.

On a 1-10 scale, I give this anime an 8.  Now I need to go find something to watch on NetFlix that is more uplifting and less disturbing!