We recently starting testing the SCOM 2012 Management Agent for Linux on a test server running CentOS 6.4 x86_64. Since we just installed a minimal set of packages via an automated kickstart the hostname of the machine wasn't set to the DNS resolved name.
After the SCOM agent was installed and even after we changed the hostname and setup the proper DNS the SCOM console was still barking about an SSL certificate common name matching the hostname of the server.
Every once in a while when I'll try to drag and drop something like an email in my Outlook Inbox to a sub-folder, or drag and drop files in my GUI FTP program and it just won't work.
My fix was just to hit the Escape key on my keyboard a few time. Poof! I can now drag and drop again.
If this doesn't work for you, make sure that one of the special keys like Alt or Ctrl aren't stuck.
Drag and drop away.
One of my resolutions for 2013 is to write and post articles more frequently. Here's my first attempt.
At my company we are heavy users of VMware/ESX/ESXi. It's what we have used for well over 8 years. One of the reasons why: it just works, it's stable, and (as it related to this post) the virtual networking is just simpler (in my opinion).
We recently upgraded our vSphere infrastructure to ESXi version 5.0 Update 1a and we were having some issues upgrading the VMware Tools.
We were getting a Microsoft Visual C++ Runtime error related to TPVCGateway.exe. It appears that this was an issue that was resolved by an ESXi 4.1 patch.
The root cause in our case was that we disable the Print Spooler on all of our servers for security. Well this disabling caused an issue with the VMware Tools uninstaller if the Thin Print virtual print driver was installed.
After patching our vCenter Server recently we were no longer able to use the "Search Inventory" box to search our virtual infrastructure. When we tried we would receive the following error:
Login to the query service failed. Unable to connect ...
The full error text has been abbreviated.
We were getting the following error trying to deploy a new WCF service because the domain account which runs the service was not a local admin on the server on which it was installed:
Service cannot be started. System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL http://+:8000/ourservice/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details).
The easy fix would have been to add the user as a local admin, but that's not the most security way to resolve the issue.
We are implementing a pilot of Microsoft Lync 2010 and we've been running in to a few little quirks.
We are using a Dialogic DMG VoIP gateway to interface with our legacy telephony equipment to receive calls from the PSTN.
Here is the current quirk that was encountered: any call that originated from the PSTN to a Lync user that was placed on hold would disconnect after exactly 90 seconds. The following information was observed in a Lync trace of the call:
