I recently demoted an old Domain Controller in an effort to move forward in my domain - it was a 32-bit 2008 Server, and all the rest of the DCs are 2008R2 or 2012R2. I don't have any needs today to move up AD functionality today (we are already on 2008 Forest and Domain Functionality), but it never hurts to be ready.
After demoting an old Domain Controller, I recently started receiving Error 9385 on one of my Exchange 2010 Mailbox servers:
Log Name: Application
Source: MSExchangeSA
Date: 6/2/2015 8:43:34 AM
Event ID: 9385
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: MailboxSVR.internal.domain
Description:
Microsoft Exchange System Attendant failed to read the membership of the universal security group '/dc=domain/dc=internal/ou=Microsoft Exchange Security Groups/cn=Exchange Servers'; the error code was '8007203a'. The problem might be that the Microsoft Exchange System Attendant does not have permission to read the membership of the group.
If this computer is not a member of the group '/dc=domain/dc=internal/ou=Microsoft Exchange Security Groups/cn=Exchange Servers', you should manually stop all Microsoft Exchange services, run the task 'add-ExchangeServerGroupMember,' and then restart all Microsoft Exchange services.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="MSExchangeSA" />
<EventID Qualifiers="49152">9385</EventID>
<Level>2</Level>
<Task>1</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2015-06-02T13:43:34.000000000Z" />
<EventRecordID>2199039</EventRecordID>
<Channel>Application</Channel>
<Computer>MailboxSVR.internal.domain</Computer>
<Security />
</System>
<EventData>
<Data>/dc=com/dc=wmfingrp/dc=internal/ou=Microsoft Exchange Security Groups/cn=Exchange Servers</Data>
<Data>8007203a</Data>
</EventData>
</Event>
After doing some research, most articles said that you need to make sure that it's a member of the group, etc, but all of that was correct. There weren't any references to the old DC in anything I checked (DNS was pointed elsewhere, Domain controllers and Global catalog servers that this Exchange server used were pointed elsewhere, etc). But, I knew it had to do with my demoted DC. For some reason this particular Exchange server was really hoping that the DC would answer his requests. I didn't notice any other performance or user issues during this time, so it looks like the Exchange server was able to get his answer elsewhere after checking here.
Once I was able to take a maintenance window, I rebooted the affected Exchange server, and all was well. It just needed to clear it's head after loosing it's good friend.
------
Dustin Shaw
VCP
Showing posts with label Error. Show all posts
Showing posts with label Error. Show all posts
Tuesday, June 2, 2015
Tuesday, March 31, 2015
Outlook Sync Issues
Synchronization issues are something that seem to plague any Exchange Admin. They come up for no reason, and go away for no reason. There have been a number of posts on the issue over the years, most telling MS to go fix their issues.
One particular issue that I've seen recently is when moving a database from one Exchange 2010 DAG Member to another, the Sync Issues folder starts filling up with the following Synchronization Log messages:
Checking all the normal locations, there is nothing wrong with the synchronization, yet every 5 minutes Outlook reports an error synchronizing. The above example is with Outlook 2013 on Exchange 2010 SP3 RU6, but I've seen it through several Service Packs and Rollups. The issue also shows up on Outlook 2010.
Looking through all the settings on the Exchange DAG Members, and the Client Access Server in use (which doesn't change during the failover), there is nothing out of the ordinary that might keep it from syncing.
If I find a solution to this particular issue, I'll post it back here for posterity. Until then, this is merely another "Microsoft, please fix you're sync problems" blog.
------
Dustin Shaw
VCP
One particular issue that I've seen recently is when moving a database from one Exchange 2010 DAG Member to another, the Sync Issues folder starts filling up with the following Synchronization Log messages:
7:57:57 Synchronizer
Version 15.0.4701
7:57:57 Synchronizing
Mailbox 'User Name'
7:57:57 Synchronizing
Hierarchy
7:57:58 Synchronizing
server changes in folder 'Inbox'
7:57:58 Downloading from
server 'Client-Access-Server'
7:57:58 1
item(s) added to offline folder
7:57:58 Error
synchronizing folder
7:57:58 [8004010F-501-8004010F-0]
7:57:58 The client operation failed.
7:57:58 Microsoft Exchange Information Store
7:57:58 For more information on this failure, click
the URL below:
7:57:58 http://www.microsoft.com/support/prodredirect/outlook2000_us.asp?err=8004010f-501-8004010f-0
7:57:58 Canceled
Checking all the normal locations, there is nothing wrong with the synchronization, yet every 5 minutes Outlook reports an error synchronizing. The above example is with Outlook 2013 on Exchange 2010 SP3 RU6, but I've seen it through several Service Packs and Rollups. The issue also shows up on Outlook 2010.
Looking through all the settings on the Exchange DAG Members, and the Client Access Server in use (which doesn't change during the failover), there is nothing out of the ordinary that might keep it from syncing.
If I find a solution to this particular issue, I'll post it back here for posterity. Until then, this is merely another "Microsoft, please fix you're sync problems" blog.
------
Dustin Shaw
VCP
Wednesday, March 18, 2015
Brother ControlCenter4 Scanning Permissions
Brother ControlCenter4 Scanning to File requires certain permissions to write files to the folder. These permissions use the current logged in user permissions. To test that the write permissions are accessible, ControlCenter4 appears to write a .tmp file and create a temp folder. I say appears because I have not found any documentation on the subject.
I ran across these required permissions because a scanner I support was trying to write to a network share that allowed Full Access MINUS the ability to create folders. Without the ability to create folders, it would drop a .tmp file in the folder on scan, and pop up an Unable to write the file to "Destination Folder". error like the below:
Once I assigned the user the ability to create folders in this directory (only), ControlCenter4 was able to scan properly.
------
Dustin Shaw
VCP
Friday, October 10, 2014
Deploying vCOPS 5.x in vSphere Essentials Plus
VMware vCenter Operations Manager 5.x has a requirement for DRS (Distributed Resource Schedule) to be able to be deployed in a cluster - this is because it is deployed as a vApp, and vApps require DRS.
If you are attempting to install vCOPS on vSphere Essentials, Essentials Plus, or Standard, you will discover that you don't have license for DRS. VMware released this article as the resolution to the problem. Here are the steps that they detailed:
---
To deploy vCenter Operations Manager in a vCenter Server environment with an Essentials Plus or Standard cluster of three ESX hosts:
- Remove one of the ESX hosts from the cluster so that it resides directly under the parent datacenter.
- On that ESX host, deploy the vCenter Operations Manager vApp, specifying static IP addresses.
- Power on the vApp before moving the host back into the cluser to ensure IP settings are picked up.
- License the solution in vCenter.
- Move the ESX host with vCenter Operations back into the cluster.
Warning: The steps above dissolve the vApp container and an error is displayed. Disregard the error message and continue moving the host into the cluster.
Moving the ESX host with the vCenter Operations vApp back into the cluster results in the addition of the two virtual machines (the UI virtual machine and the Analytics virtual machine) to the cluster, without the vApp container. vCenter Operations Manager 5.x continues to function normally when this happens.
---
Also, in case you need it, the default logins for vCOPS are:
Default Administration:
admin
admin
Default Root Login:
root
vmware
------
Dustin Shaw
VCP
Monday, September 8, 2014
User exceeded the maximum of 250 objects of type "objtMessage".
I have users that are regularly exceeding 250 objtMessage objects in Exchange 2010. What this really means is that the user has over 250 Messages open at once. While this seems high, when you consider third party tools and other such things, 250 is really not that much. I actually have a couple of users that regularly spike over 500 on a daily basis.
Whenever this behavior exhibits itself, it's in the form of ERROR in the Application log with EventID 9646. The text reads:
Mapi session "64807ed0-b1b3-4938-92e3-b9dbd9cfe67b: /o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User Name" exceeded the maximum of 250 objects of type "objtMessage".
The default setting for this (and other open item limits in Exchange 2010) is detailed in Microsoft's Exchange Store Limits article.
To change from the default settings, open the registry on your Mailbox Server, and navigate to the following key:
HKLM\SYSTEM\ConcurrentControlSet\services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession
Update/create the DWORD named objtMessage and give it the decimal value that you need (up it to 500).
Don't forget if you are in a DAG to repeat the registry entries on all Mailbox Servers.
------
Dustin Shaw
VCP
Wednesday, July 30, 2014
The symbolic link cannot be followed
When you setup symbolic links on a server that point to another server, you will by default run into the inability for a client computer to follow the links with the following error:
The symbolic link cannot be followed because its type is disabled.
This is because the ability to traverse from one remote system to another across the symbolic link is disabled by default. You can see what is disabled and what is enabled on a computer by running the fsutil command:
>fsutil behavior query eymlinkevaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.
You have two methods to enable this - enable it locally on each machine, or enable it via Group Policy.
fsutil behavior set symlinkevaluation R2R:1
Similarly, you can change the settings for Local to Local (L2L), Local to Remote (L2R), and Remote to Local (R2L) by using 1 for enabled and 0 for disabled.
Computer Configuration -> Administrative Templates -> System -> Filesystem
You can then set the settings how you want in Selectively allow the evaluation of a symbolic link
Once you've created your new GPO, test it and validate that it is successfully applied using gpresult /R and rsop.
The symbolic link cannot be followed because its type is disabled.
This is because the ability to traverse from one remote system to another across the symbolic link is disabled by default. You can see what is disabled and what is enabled on a computer by running the fsutil command:
>fsutil behavior query eymlinkevaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.
You have two methods to enable this - enable it locally on each machine, or enable it via Group Policy.
Local
The downsides to enabling it locally are obvious, but sometimes you just need it on one stubborn computer *right now* and can't wait for GP. To enable Remote to Remote symbolic links, run the following command:fsutil behavior set symlinkevaluation R2R:1
Similarly, you can change the settings for Local to Local (L2L), Local to Remote (L2R), and Remote to Local (R2L) by using 1 for enabled and 0 for disabled.
Group Policy
To enable (or disable) Remote to Remote symbolic links in Group Policy, create a new GPO Policy (or edit a current one), and edit it. Navigate to:Computer Configuration -> Administrative Templates -> System -> Filesystem
You can then set the settings how you want in Selectively allow the evaluation of a symbolic link
Once you've created your new GPO, test it and validate that it is successfully applied using gpresult /R and rsop.
Thursday, May 15, 2014
The wizard was interrupted before VMware Tools could be completely installed.
Upon attempting to install VMware Tools on a Windows Server 2008R2 server, I received an error stating "The wizard was interrupted before VMware Tools could be completely installed."
After looking around on the internet, the closest thing I could find was this post by David Homer, detailing a similar issue with VMware Tools on VMware Workstation.
I tried his fixes (remove VMware Tools registry key, remove the vmtools service), but none of them allowed me to get past the problem.
What eventually worked was doing a search in the registry for all references to "vmware" and removing all keys having to do with VMware Tools - make sure you don't remove any of the keys referring to your SCSI devices/other hardware; just the VMware Tools entries.
I believe it was most likely the Installer registry entries that were mucking it up.
After a quick reboot to refresh the registry, VMware Tools installed with no issues.
------
Dustin Shaw
VCP
After looking around on the internet, the closest thing I could find was this post by David Homer, detailing a similar issue with VMware Tools on VMware Workstation.
I tried his fixes (remove VMware Tools registry key, remove the vmtools service), but none of them allowed me to get past the problem.
What eventually worked was doing a search in the registry for all references to "vmware" and removing all keys having to do with VMware Tools - make sure you don't remove any of the keys referring to your SCSI devices/other hardware; just the VMware Tools entries.
I believe it was most likely the Installer registry entries that were mucking it up.
After a quick reboot to refresh the registry, VMware Tools installed with no issues.
------
Dustin Shaw
VCP
Wednesday, April 30, 2014
Graylog2 Version Check Errors
I noticed periodic warnings in my Graylog2 0.20.1 instance saying:
WARN : org.graylog2.periodical.VersionCheckThread - Could not perform version check
The fix for this (as detailed here in Google Groups by Lennart Koopmann) is to set an undocumented flag in your /etc/graylog2.conf as follows:
versionchecks = false
------
Dustin Shaw
VCP
WARN : org.graylog2.periodical.VersionCheckThread - Could not perform version check
The fix for this (as detailed here in Google Groups by Lennart Koopmann) is to set an undocumented flag in your /etc/graylog2.conf as follows:
versionchecks = false
------
Dustin Shaw
VCP
Thursday, July 19, 2012
vRanger error "There is an error in XML document"
I ran into an issue with one of our repositories - every job in the particular repository was failing with the error:
An internal error occurred during execution, please contact Quest support if the error persists. Error Message: There is an error in XML document (823, 223).
This error is commonly caused by a corruption or issue with the manifest file as detailed here.
To fix it, go into the manifest file for the repository (GlobalManifest.metadata), make sure that all trailing brackets are closed, and add </vRangerGlobalManifestFile> at the end of the document.
Save and test.
------
Dustin Shaw
VCP
An internal error occurred during execution, please contact Quest support if the error persists. Error Message: There is an error in XML document (823, 223).
This error is commonly caused by a corruption or issue with the manifest file as detailed here.
To fix it, go into the manifest file for the repository (GlobalManifest.metadata), make sure that all trailing brackets are closed, and add </vRangerGlobalManifestFile> at the end of the document.
Save and test.
------
Dustin Shaw
VCP
Thursday, February 23, 2012
Host update fails after updating to 4.1u2
After updating vCenter Update Manager (right after updating my vCenter Server) from 4.1u1 to 4.1u2, I received the following error when trying to update on of my hosts:
Remediation did not succeed for esxihost: SingleHostRemediate: esxupdate error, version: 1.30, operation: 7: ('http://esxihost:9084/vci/hostupdates/hostupdate/vmw/vibs/cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib','/var/tmp/cache/-1699692350','[Errno 14] HTTP Error 404: Not Found')
After doing some research, I discovered what happened is that Update Manager 4.1u2 is case sensitive, whereas 4.1u1 was not. Any patches that were downloaded previous to the 4.1u2 update that contain upper case letters will fail with this error. VMware has a KB article about it here.
The patches affected are the ones below. I've put the correct capitalization on them for you. If you go to your patch repository, you can rename the files that you have to the below, and you should then be able to update your hosts. The repositories are located here:
bind-libs-9.3.6-4.P1.el5_5.3.i386.vib
bind-libs-9.3.6-4.P1.el5_5.3.x86_64.vib
bind-utils-9.3.6-4.P1.el5_5.3.x86_64.vib
bind-libs-9.3.6-4.P1.el5_5.3.i386.vib
cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib
cross_oem-vmware-esx-drivers-scsi-3w-9xxx_400.2.26.08.036vm40-1OEM.vib
vmware-esx_swMgmt_provider-4x.1.0.1-1.4.348481.vib
------
Dustin Shaw
VCP
Remediation did not succeed for esxihost: SingleHostRemediate: esxupdate error, version: 1.30, operation: 7: ('http://esxihost:9084/vci/hostupdates/hostupdate/vmw/vibs/cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib','/var/tmp/cache/-1699692350','[Errno 14] HTTP Error 404: Not Found')
After doing some research, I discovered what happened is that Update Manager 4.1u2 is case sensitive, whereas 4.1u1 was not. Any patches that were downloaded previous to the 4.1u2 update that contain upper case letters will fail with this error. VMware has a KB article about it here.
The patches affected are the ones below. I've put the correct capitalization on them for you. If you go to your patch repository, you can rename the files that you have to the below, and you should then be able to update your hosts. The repositories are located here:
- Windows2008: C:\ProgramData\VMware\VMware Update Manager\Data\Hostupdate\vmw\vib\
- Windows2003: C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\Hostupdate\vmw\vib
bind-libs-9.3.6-4.P1.el5_5.3.i386.vib
bind-libs-9.3.6-4.P1.el5_5.3.x86_64.vib
bind-utils-9.3.6-4.P1.el5_5.3.x86_64.vib
bind-libs-9.3.6-4.P1.el5_5.3.i386.vib
cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib
cross_oem-vmware-esx-drivers-scsi-3w-9xxx_400.2.26.08.036vm40-1OEM.vib
vmware-esx_swMgmt_provider-4x.1.0.1-1.4.348481.vib
------
Dustin Shaw
VCP
Wednesday, February 22, 2012
Syslog not configured on ESXi 4.1u2
When I updated my ESXi host from 4.1u1 to 4.1u2, I got the following error message:
Configuration Issues
Issue detected on esxihost in datacenter: Warning: Syslog not configured. Please check Syslog options under Configuration.Software.Advanced Settings in vSphere client.
I thought it was odd since the host previously never complained about the Syslog before. I compared the settings between it and the other 4.1u2 hosts that I had, and indeed, it was missing the Syslog.Local.DatastorePath setting.
The setting on my hosts was:
[] /scratch/log/messages
Once I copied this into my Syslog.Local.DatastorePath setting on the server, it was happy. I went ahead and copied the setting to my remaining 4.1u1 servers so that they will be happy when updated as well.
So apparently ESXi 4.1u2 has issues with the Syslog running on ramdisk, but ESXi 4.1u1 doesn't.
I found the following VMware KB Article that explains why it complains about it:
Syslog not configured messages on ESXi host console or in logs
------
Dustin Shaw
VCP
Issue detected on esxihost in datacenter: Warning: Syslog not configured. Please check Syslog options under Configuration.Software.Advanced Settings in vSphere client.
I thought it was odd since the host previously never complained about the Syslog before. I compared the settings between it and the other 4.1u2 hosts that I had, and indeed, it was missing the Syslog.Local.DatastorePath setting.
The setting on my hosts was:
[] /scratch/log/messages
Once I copied this into my Syslog.Local.DatastorePath setting on the server, it was happy. I went ahead and copied the setting to my remaining 4.1u1 servers so that they will be happy when updated as well.
So apparently ESXi 4.1u2 has issues with the Syslog running on ramdisk, but ESXi 4.1u1 doesn't.
I found the following VMware KB Article that explains why it complains about it:
Syslog not configured messages on ESXi host console or in logs
------
Dustin Shaw
VCP
Tuesday, February 21, 2012
Installing PowerCLI on Server 2008
In attempting to install VMware vSphere PowerCLI on Windows Server 2008 x64, the following error comes up. This also happens on Server 2008R2.
Error 1406. Could not write value InstallPath to key \Software\VMware, Inc.\VMware vSphere PSDK Runtime. Verify tha tyou have sufficient access to that key, or contact your support personnel.
The prescribed fix for this is to remove the following registry key (and subkeys):
HKLM\Software\Wow6432Node\VMware, Inc.
*** Please make sure you know what you are doing in the registry before you do anything in there!!!
After that, installation proceeds successfully.
The only thing under the VMware, Inc. registry key is a "volatile" key with a UUIDHost DWord under it. Since I don't like to mess with other programs installed on the server (the one I was using has Quest vRanger installed), I exported the key, removed it, installed PowerCLI, and the imported my volatile key back in.
------
Dustin Shaw
VCP
Error 1406. Could not write value InstallPath to key \Software\VMware, Inc.\VMware vSphere PSDK Runtime. Verify tha tyou have sufficient access to that key, or contact your support personnel.
The prescribed fix for this is to remove the following registry key (and subkeys):
HKLM\Software\Wow6432Node\VMware, Inc.
*** Please make sure you know what you are doing in the registry before you do anything in there!!!
After that, installation proceeds successfully.
The only thing under the VMware, Inc. registry key is a "volatile" key with a UUIDHost DWord under it. Since I don't like to mess with other programs installed on the server (the one I was using has Quest vRanger installed), I exported the key, removed it, installed PowerCLI, and the imported my volatile key back in.
------
Dustin Shaw
VCP
Thursday, February 9, 2012
ESXi Host Unable to Update
I had a VMware ESXi 4.1 host that I was unable to update/patch using Update Manager the today.
It was coming up with the following errors when I tried:
VMware vCenter Update Manager had an unknown error. Check the Tasks and Events tab and log files for details.
And when I did that, I found this:
Could not install patches on esxihostname
Remediation did not succeed for esxihostname: SingleHostRemediate: Install error on host: esxihostname, error details: vim.fault.NoHost.
So I did some quick googling, and ran across this website that had the answer I was looking for.
The particular host that I was trying to update did indeed have an Unknown (inaccessible) VM on it (left over from yanking the storage and being sloppy...). I removed the VM from inventory, then was able to successfully patch the host.
------
Dustin Shaw
VCP
It was coming up with the following errors when I tried:
VMware vCenter Update Manager had an unknown error. Check the Tasks and Events tab and log files for details.
And when I did that, I found this:
Could not install patches on esxihostname
Remediation did not succeed for esxihostname: SingleHostRemediate: Install error on host: esxihostname, error details: vim.fault.NoHost.
So I did some quick googling, and ran across this website that had the answer I was looking for.
The particular host that I was trying to update did indeed have an Unknown (inaccessible) VM on it (left over from yanking the storage and being sloppy...). I removed the VM from inventory, then was able to successfully patch the host.
------
Dustin Shaw
VCP
Friday, January 27, 2012
Datastore Alarm Not Accurate
I had the unfortunate mishap of a VM dropping offline because it outgrew the amount of free space on the datastore it existed on. On the plus side, it happened in the middle of the night and I wasn't on call :-) The on call guy simply had to reboot the box, and it came back online.
When I got in and looked, the datastore that it existed on had 0.00 B of free space. Not very comforting, considering the fact that there were no alarms on that datastore, and there were several other Production VMs on that LUN.
To fix the alarm state, it was easy. Go into the alarm definition and disable and re-enable it. This will force it to refresh it's states and you will get to see all the pretty yellow and red icons that you've been missing.
This also will work if it is reporting a Usage Above Threshold before it should too.
------
Dustin Shaw
VCP
When I got in and looked, the datastore that it existed on had 0.00 B of free space. Not very comforting, considering the fact that there were no alarms on that datastore, and there were several other Production VMs on that LUN.
To fix the alarm state, it was easy. Go into the alarm definition and disable and re-enable it. This will force it to refresh it's states and you will get to see all the pretty yellow and red icons that you've been missing.
This also will work if it is reporting a Usage Above Threshold before it should too.
------
Dustin Shaw
VCP
Tuesday, January 24, 2012
vRanger "host could not be identified"
We had our vCenter sever hiccup on us yesterday, so (naturally) our vRanger backups failed last night.
The error we received was:
An internal error occurred during execution, please contact Quest support if the error persists. Error Message: VMSERVER's host could not be identified
Essentially what causes this issue is a communication sync error between vRanger and vCenter. I ran across this error a year and a half ago running on vRanger 4.x (you can read my post here). This time it was on Quest vRanger version 5.3.0, so I did a quick search to see if there were any newer solutions for verison 5. It appears that Quest now has a KB article about it.
Basically, their solution is to restart the services - stop the API and FLR Services, restart the vRanger service, then start up the API and FLR services.
I always prefer to go above, so I also refreshed the jobs (like my previous experience taught me) by opening them up and click next and finish all the way through (without changing anything).
Next time I'll remind my guys to restart vRanger services whenever vCenter bounces.
------
Dustin Shaw
VCP
The error we received was:
An internal error occurred during execution, please contact Quest support if the error persists. Error Message: VMSERVER's host could not be identified
Essentially what causes this issue is a communication sync error between vRanger and vCenter. I ran across this error a year and a half ago running on vRanger 4.x (you can read my post here). This time it was on Quest vRanger version 5.3.0, so I did a quick search to see if there were any newer solutions for verison 5. It appears that Quest now has a KB article about it.
Basically, their solution is to restart the services - stop the API and FLR Services, restart the vRanger service, then start up the API and FLR services.
I always prefer to go above, so I also refreshed the jobs (like my previous experience taught me) by opening them up and click next and finish all the way through (without changing anything).
Next time I'll remind my guys to restart vRanger services whenever vCenter bounces.
------
Dustin Shaw
VCP
Saturday, August 13, 2011
Exchange 2010 and IE9 Issues
Ran across a known issue with Exchange 2010 and IE9. How do I know it was a known issue? I happened to be on the phone with Microsoft Support at the time for another issue...
The error that this combination causes is that you cannot close the Exchange Management Console in Exchange 2010. When you try to close it you receive the error message "You must close all dialog boxes before you can close Exchange Management Console."
My friendly guy on the Microsoft call told me that there is currently no fix - they are expecting to have a patch out around Q4 2011. The current fix, according to him, was "Don't install it. And uninstall it if you have already." I almost forgot to mute the phone before I started laughing. Gotta love when Microsoft tells you to not keep your computer up to date because it will break it...
So I decided to do some research on my own and (easily) found an article here with the fix.
Basically what you need to do is disable the Internet Explorer Enhanced Security Configuration, then add https://localhost to the trusted sites in IE and your good to go.
------
Dustin Shaw
VCP
The error that this combination causes is that you cannot close the Exchange Management Console in Exchange 2010. When you try to close it you receive the error message "You must close all dialog boxes before you can close Exchange Management Console."
My friendly guy on the Microsoft call told me that there is currently no fix - they are expecting to have a patch out around Q4 2011. The current fix, according to him, was "Don't install it. And uninstall it if you have already." I almost forgot to mute the phone before I started laughing. Gotta love when Microsoft tells you to not keep your computer up to date because it will break it...
So I decided to do some research on my own and (easily) found an article here with the fix.
Basically what you need to do is disable the Internet Explorer Enhanced Security Configuration, then add https://localhost to the trusted sites in IE and your good to go.
------
Dustin Shaw
VCP
Friday, June 24, 2011
View Pool Issues
Had a client call me this morning with an issue with one of his VMware View 4.5 pool. He said that his users were having issues logging into their desktops. They could login, but it was taking a long time to login. When he went to double check the settings in the pool he found that his vCenter Settings tab was red and the error it stated:
Cannot find host or cluster for this pool.
Since I set it all up for him initally, he stopped there and thought he'd better differ to the expert. Oh, and yes it does say "Data-Denter" - he's dislexic (aren't we all?)
I dug in further and found the following other errors. When clicking on "Browse" to chose Host or cluster, I received this error:
Server Error
One of the required objects is not found in vCenter Server vcenter.
When I looked at the desktops, they all had the same error listed:
Status
Resource Cluster \'/Data-Center/host/Cluster/Resources\' not found for pool: Poolname
Since it was a Floating resource pool with no persistent desktops, I decided the quickest and easiest thing to do for him would be to just create a new pool based of the same image (I'm going to have to give him a refresher on Recomposing; it looks like he is still running off the image I helped him create over a year ago). I disabled his old pool and told him to delete it once he felt comfortable that everything was running good on the new one.
Afterwords, I decided to glance around for an answer, and found this VMware KB article:
Editing an existing pool in the VMware View web admin interface fails with the error: One of required objects is not found in the VirtualCenter server <IP address>
Nothing has changed on his environment. He only has the vSphere Essentials bundle (he has a small shop with only 2 hosts), so he doesn't have any actual Resource Clusters. This is my thought as to where the corruption came from, but I've got nothing to confirm my suspicions. If anyone has some thoughts on this, I'd love to hear them.
------
Dustin Shaw
VCP
Cannot find host or cluster for this pool.
Since I set it all up for him initally, he stopped there and thought he'd better differ to the expert. Oh, and yes it does say "Data-Denter" - he's dislexic (aren't we all?)
I dug in further and found the following other errors. When clicking on "Browse" to chose Host or cluster, I received this error:
Server Error
One of the required objects is not found in vCenter Server vcenter.
When I looked at the desktops, they all had the same error listed:
Status
Resource Cluster \'/Data-Center/host/Cluster/Resources\' not found for pool: Poolname
Since it was a Floating resource pool with no persistent desktops, I decided the quickest and easiest thing to do for him would be to just create a new pool based of the same image (I'm going to have to give him a refresher on Recomposing; it looks like he is still running off the image I helped him create over a year ago). I disabled his old pool and told him to delete it once he felt comfortable that everything was running good on the new one.
Afterwords, I decided to glance around for an answer, and found this VMware KB article:
Editing an existing pool in the VMware View web admin interface fails with the error: One of required objects is not found in the VirtualCenter server <IP address>
Nothing has changed on his environment. He only has the vSphere Essentials bundle (he has a small shop with only 2 hosts), so he doesn't have any actual Resource Clusters. This is my thought as to where the corruption came from, but I've got nothing to confirm my suspicions. If anyone has some thoughts on this, I'd love to hear them.
------
Dustin Shaw
VCP
Wednesday, April 20, 2011
Purple Screen of Death - Dell issues
You may notice I don't post a lot of issues on here. That's because we frankly don't have a whole lot of issues. I personally attribute it to using Best Practices, and regular maintenance. That said, things will still get lost in the weeds occasionally.
We ran into the Purple Screen of Death on one of our ESX 4.1 boxes yesterday. It is a Dell R610, and apparently had a hardware hiccup, and kicked out errors stating:
We rebooted the box, and it came back online just fine, but we didn't feel comfortable with it, so we stuck it in maintenance mode and had someone contact Dell. Dell reports that we need to update the Bios on it:
-----
Yes, it appears your system is affected by some of the microcode updates released from Intel on the 5500 and 5600 series processors. That is likely the cause of these PCI errors. The course of action we need to take is:
· Update the BIOS
· Update the iDRAC
· Clear out the old log entries
· Monitor for re-occurance.
------
So it's sitting in maintenance mode until someone has some time to love on it. The awesome thing is that we run N+1 (one more box than we need) so we have that luxury. I know plenty of people that refuse to listen to why you should go N+1 who would be scrambling to make a maintenance window to update it.
The downside to this whole fiasco was that when it hiccupped, it stayed online (as is the default with ESX), and held onto the Storage of it's VMs. Therefore, HA couldn't restart them on another box until someone manually SHUT OFF the pretty Purple-VM-Eater. As soon as they did that, all was well in the world and the phone stopped ringing.
Since I'm not fond on relying on manual intervention to make HA work, I found the command for auto-restart when a PSoD happens and applied to ALL our hosts:
esxcfg-advcfg -s X /Misc/BlueScreenTimeout
Were X = number of seconds before restart
I went with 30 seconds, that way I have the opportunity of seeing the screen if I so happen to be looking at it when it dies.
------
Dustin Shaw
VCP
We ran into the Purple Screen of Death on one of our ESX 4.1 boxes yesterday. It is a Dell R610, and apparently had a hardware hiccup, and kicked out errors stating:
| | | Tue Apr 19 21:09:15 2011 | | PCIE Fatal Err: Critical Event sensor, bus fatal error (Bus 1 Device 0 Function 1) was asserted | | 0xA10002FBF9AD4DB1000413186FAA0101h |
| | | Tue Apr 19 21:09:15 2011 | | Err Reg Pointer: OEM sensor, OEM Diagnostic data event was asserted | | 0xA00002FBF9AD4DB10004C11A7E011610h |
| | | Tue Apr 19 21:09:15 2011 | | PCIE Fatal Err: Critical Event sensor, bus fatal error (Bus 1 Device 0 Function 0) was asserted | | 0x9F0002FBF9AD4DB1000413186FAA0001h |
| | | Tue Apr 19 21:09:15 2011 | | Err Reg Pointer: OEM sensor, OEM Diagnostic data event was asserted | | 0x9E0002FBF9AD4DB10004C11A7E011610h |
We rebooted the box, and it came back online just fine, but we didn't feel comfortable with it, so we stuck it in maintenance mode and had someone contact Dell. Dell reports that we need to update the Bios on it:
-----
Yes, it appears your system is affected by some of the microcode updates released from Intel on the 5500 and 5600 series processors. That is likely the cause of these PCI errors. The course of action we need to take is:
· Update the BIOS
· Update the iDRAC
· Clear out the old log entries
· Monitor for re-occurance.
------
So it's sitting in maintenance mode until someone has some time to love on it. The awesome thing is that we run N+1 (one more box than we need) so we have that luxury. I know plenty of people that refuse to listen to why you should go N+1 who would be scrambling to make a maintenance window to update it.
The downside to this whole fiasco was that when it hiccupped, it stayed online (as is the default with ESX), and held onto the Storage of it's VMs. Therefore, HA couldn't restart them on another box until someone manually SHUT OFF the pretty Purple-VM-Eater. As soon as they did that, all was well in the world and the phone stopped ringing.
Since I'm not fond on relying on manual intervention to make HA work, I found the command for auto-restart when a PSoD happens and applied to ALL our hosts:
esxcfg-advcfg -s X /Misc/BlueScreenTimeout
Were X = number of seconds before restart
I went with 30 seconds, that way I have the opportunity of seeing the screen if I so happen to be looking at it when it dies.
------
Dustin Shaw
VCP
Thursday, February 10, 2011
VMware View Client Fails to Connect
If you just recently installed Microsoft Windows Updates on your Windows 7 machine, you'll soon discover that two of them broke the VMware View Client 4.5.
VMware recommends in their KB Article that you update to the latest patch of the View Client (the latest patch available on their website is Build 353760), or uninstall the two offending MS Updates (KB2482017 & KB2467023).
Essentially the two patches are to fix holes in Internet Explorer and to address issues that occur when the system binaries are unloaded and loaded. Installing either of these updates will break the VMware View Client so that it will not connect to the View Connection Server. The behavior I experienced was that it appeared as if the VMware View Client locked up after I clicked on Connect.
To fix it, simply download the patch, install, and your back in the game.
Here's the text of the VMware KB Article for your convinience:
------
Dustin Shaw
VCP
VMware recommends in their KB Article that you update to the latest patch of the View Client (the latest patch available on their website is Build 353760), or uninstall the two offending MS Updates (KB2482017 & KB2467023).
Essentially the two patches are to fix holes in Internet Explorer and to address issues that occur when the system binaries are unloaded and loaded. Installing either of these updates will break the VMware View Client so that it will not connect to the View Connection Server. The behavior I experienced was that it appeared as if the VMware View Client locked up after I clicked on Connect.
To fix it, simply download the patch, install, and your back in the game.
Here's the text of the VMware KB Article for your convinience:
Unable to connect from the View Client on Windows 7 to the View Connection Server after installing the patch in Microsoft Knowledge Base article 2482017 or 2467023
------
Dustin Shaw
VCP
Thursday, November 11, 2010
vsd-mount [!!] Error
Ran into this on one of our ESX hosts recently after shutting it down for some maintenance:
* vsd-mount ... [!!]
You have entered the recovery shell. The situation you are in may be recoverable. If you are able to fix this situation the boot process will continue normally after you exit this terminal
/bin/sh: can't access tty; job control turned off
/ #
I was unable to get in troubleshooting mode on the ESX box, so I couldn't run any commands of consequence. I perused around and determined pretty quickly that reloading was my quickest and easiest option. After all, we've got a Distributed Switch setup, and the rest are just basics (IP, etc), so it wasn't a very hard decision.
------
Dustin Shaw
VCP
* vsd-mount ... [!!]
You have entered the recovery shell. The situation you are in may be recoverable. If you are able to fix this situation the boot process will continue normally after you exit this terminal
/bin/sh: can't access tty; job control turned off
/ #
I was unable to get in troubleshooting mode on the ESX box, so I couldn't run any commands of consequence. I perused around and determined pretty quickly that reloading was my quickest and easiest option. After all, we've got a Distributed Switch setup, and the rest are just basics (IP, etc), so it wasn't a very hard decision.
------
Dustin Shaw
VCP
Subscribe to:
Posts (Atom)