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:
Ever had a server that seems to run out of space only to find the the System Volume Information folder is using a TON of space?
Volume Shadow Copies were the problem in our case. Here is a link to explain exactly what Volume Shadow Copies are:
WCF Web Services, IIS, Kerberos, and Delegation problems are maddening!
Sometimes you implement something exactly as you have in the past, but due to some unforeseen circumstance it doesn't work as you expect. We've seen issues like this when implementing WCF web services on IIS 6.
Some things you can check are:
- Have you setup the proper service principal names for the service account running the application pool?
- Is the service account setup to run the application pool that is running the web service trusted for delegation?
Well we had an interesting problem this week. For some reason all of a sudden, users with Outlook 2010 started to have the application crash when they tried to open the application. Outlook would open fine in safe mode and if the user re-created their mail profile everything would work fine - until they rebooted.
After a reboot Outlook would again crash with an APPCRASH error with the culprit being olmapi32.dll.
It seems that radio buttons on forms displayed/rendered with SharePoint 2007 Infopath Forms Services are not working properly.
We have some internal custom forms on our SharePoint 2007 farm that are provided via InfoPath Forms Services. After I upgraded to the recently release Internet Explorer 9 Beta I could no longer select a radio button displayed on an InfoPath Form Services form.
Guess we'll need to file a bug on this one.
