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:
  1. Remove one of the ESX hosts from the cluster so that it resides directly under the parent datacenter.
  2. On that ESX host, deploy the vCenter Operations Manager vApp, specifying static IP addresses.
  3. Power on the vApp before moving the host back into the cluser to ensure IP settings are picked up.
  4. License the solution in vCenter.
  5. Move the ESX host with vCenter Operations back into the cluster.
Note: Static IP addresses are required.

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.

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.

Monday, July 28, 2014

How to use Group Policy to allow the users to chose any screensaver except (None)

I just found one of the most beautiful Group Policies that I've ever come across:

How to use Group Policy to allow the users to chose any screensaver except (None)

This post is from Group Policy Central, and is 4 years old, but I've verified that it works properly with Windows 7 and 8, and is just a beautifully done Group Policy. Thanks Kevin for creating it and thank Alan for sharing.

The below is excerpts from the posting:

Step 1. Edit a Group Policy Object (GPO) that is targeted to the users accounts you wan to apply this policy
Step 2. Navigate to User Configuration > Preferences > Windows Settings > Registry then from the menu click on Action > New > Registry Item

Step 3. Select “Update” from the Action then type “Control Panel\Desktop” in the Key Path: text field then type “SCRNSAVE.EXE”  in the Value Name text field and “C:\Windows\System32\scrnsave.scr” in the Value data: text field.

Step 4. Click on the Common tab and then tick “Item-level targeting” and then click the “Targeting…” button.

Now we will target the screen saver to apply only when the “HKCU\Control Panel\Desktop\SCRNSAVE.EXE” registry key does NOT exist as this means the screen saver has been configured to “(None)”.
Step 5. Click on “New Item” then the “Registry Match” option.

Step 6. Select the “Value exists” Match type” then type “Control Panel\Desktop” in the key path field and then type “SCRNSAVE.EXE” in the value name field

Step 7. Click back on the targeting setting in the top pane and press “F8” which changes the option to “does not exist” then click OK and OK.

This policy will now apply the blank screen saver on the next group policy refresh to all targeted users whenever they select the “(None)”.


Saturday, July 19, 2014

Installing Exchange Server 2010 SP3 Rollup 6

To get the permissions correct for installing Rollups on Exchange 2010 SP3, you will need to either disable UAC (not recommended) or you will need to launch the Rollup installer from an elevated command prompt (Right click and Run as Administrator) with the following command:
msiexec /update Exchange2010-KB2936871-x64-en.msp

This will allow the rollup to install properly. Other words, it will Roll Back and say that it Ended Prematurely.

Another note on Rollup 6 for SP3 is that it takes (at least in my environment) an extremely long time to generate native images for .NET assemblies. One of my servers took 45 minutes for this process. Wait it out and you'll be able to get it installed, just plan your windows accordingly.

------
Dustin Shaw
VCP

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

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