Updating vCenter Plug-in Registration URL's (from IP address to DNS) using PowerCLI

I've found this post by Josh Perkins helpful in more ways than the one demonstrated.  It's allowed me to not only update my vcops plugin registration w/ vCenter, but also helped me to update my Dell vCenter plug-in so that it connects via its DNS address rather than its IP.

http://www.vstable.com/2012/04/02/vcenter-operations-5-x-vcenter-plugin-uses-ip-instead-of-dns-hostname/

However, I decided to explore the possibility of using PowerCLI to fix these registrations.
Turns out you can and the change is immediate, so you don't have restart the vCenter service.
YAY!  No more cert errors!  You still have to ssh into the vCOPs UI vm and update the viClientConfig.xml file, but that's easy enough.

Here is my result (specifically for vCOPs):

$BaseURL = "https://myvCOPsRegisteredDNS.Name.local"
$ExtURL = "/vcops-vsphere/"
Connect-VIServer my1stvCenterServer, my2ndvCenterServer
Foreach ($DefaultVIServer in $global:DefaultVIServers)
{
    $VIServerExtensionManager = Get-View -Server $DefaultVIServer ExtensionManager
    $vcopsext = $VIServerExtensionManager.ExtensionList | where {$_.key -match "com.vmware.vcops"}
    ($vcopsext.server | where {$_.url -match "viClientConfig"}).url = ($BaseURL + $ExtURL + "viClientConfig.xml")
    ($vcopsext.client | where {$_.url -match "vcops-ngc.zip"}).url = ($BaseURL + $ExtURL + "vcops-ngc.zip")
    # If you don't $null the below properties, then the objects underneath these produce errors in updating because those object properties are required.
    $vcopsext.ExtendedProductInfo = $null
    $vcopsext.solutionManagerInfo = $null
    $VIServerExtensionManager.UpdateExtension($vcopsext)
}

PernixData: What is it? Does vSAN render it obsolete?

What is it?:
Simply put, it's flash acceleration.  You install a VIB in ESXi and register the PernixData Management (virtual management appliance) plugin to vCenter.  You can then take flash drives from each of your ESXi servers and clump them together to make a flash tier across all your hosts.

Does vSAN render it obsolete?:
Not really, it's a good solution to augment any existing SAN you might have.  It also won't require much change.  The scenery maybe changes as vSAN increases its configs max and traditional SANs fade, but that probably won't be for a long while.

The cool things:

1. You can use any SSD you want.  You don't have to purchase high-end or vendor specific SSD's.
2. Reads and Writes can be accelerated.
1. If the SSD fails, if configured, replicates that write to another SSD in the cluster.
2. Yes, you would use network bandwidth @ this point only until the failed SSD is replaced.
3. Most flash caching will only do reads because write redundancy can be somewhat problematic.
3. If you use something like NetApps backup and recovery services, you don't have to replace it because you are not inherently changing anything.
1. vSAN you would likely need to look @ a third-party or for small implementation VMware's backup solution.
2. Assuming PernixData will support NFS in the future.
4. Usable from ESXi 5.0
1. vSAN requires 5.5 U1

This is a good in-between vSAN and standard monolithic SAN arrays.  If you are using NFS, unfortunately, you are out of luck currently.  Support for NFS is supposed to be on the way though.

You can find out more here:

http://www.pernixdata.com/products/faq

VMware vSphere Profile-driven Storage Service not starting/running...

Summary:
Really a benign error especially if you don't use the function, but quite annoying if vCOPs is looking @ vCenter health.

Resolution/Workaround:
In my case, it appeared as though the vSphere Web Client service was conflicting w/ this Profile-Driven storage service.

1. Stop vSphere Web Client service
2. Start VMware vSphere Profile-driven Storage Service.
3. Start vSphere Web Client service.

For some reason this works and the web client seems to have a bit more intelligence in choosing ports  to connect to rather than the storage service which gives up the second a port it tried is in use.  Probably a hard-coded thing.

Other Notes:

If you are using the vSphere web client (which I wouldn't even bother with until 5.5 or newer), then it might make sense to install it on a different server to mitigate this issue.  Another possibility is to set its service to a delayed start.

Connect-VIServer not connecting to vCSA 5.5 U1 using windows integrated authentication...

Summary:
Connect-VIserver MyvCSAServer was not connecting using my service account's (for scheduled tasks) windows account.  It would always prompt for credentials.  Fairly odd since it has permissions and is able to connect to several other vCenters w/o inputting credentials.

By the way, this is very convenient since I don't have to insert passwords anywhere in clear text or come up w/ some crazy solution to encrypt the password.

Solution/Workaround:
Simply log into the web client using the service account once.  Once authenticated, powerCLI should not have prompt for credentials.

[This applied when the VCSA's default identity source is set to Active Directory (Windows Integrated Authentication) and is set as the default domain.  Active Directory as a LDAP server option will not work.]

Hypothesis:
I'm guessing this is some kind of weird SSO thing, where the account needs to get locally cached prior to allowing Windows integrated authentication.  It also makes me wonder if my service account were enabled for impersonation whether I would have had to manually authenticate first.

Additional Info:
Alan Renouf posted about this awhile back, but didn't come up in my google searches for some reason.
http://blogs.vmware.com/PowerCLI/2013/03/back-to-basics-connecting-to-vcenter-or-a-vsphere-host.html

SQL Connection Delay!?

Summary:
Just another standard maintenance, upgrading vCenter from 5.0 U2 to U3.  Nothing special to see here.  Oh wait, it failed?  CRAP.  Restore database, try again.  Can't build vCenter Repository?!  Crap, restore database, try again.  AGAIN!!?  Long story short, SQL Authentication specified in the ODBC connection was experiencing intermittent connection issues.  Windows integrated was much more stable.

Behavior:
Opened ODBC --> Configure ODBC connection --> Enter SQL Credentials -->  Next... wait --> Error (See below for errors) --> Click OK --> Select Next again --> successfully connects and tests successfully.  Repeat...

Hypothesis:
This problem was likely due to the firewall in-between the vCenter server and SQL server.  As to what that problem was exactly, I have no clue.

Solution/WorkAround:
Changed ODBC connection from SQL Authenticated User to Windows Integrated.  For this to work, you have to change the following:

1. Change the following services to start as a windows service account that has dbo control over the vCenter database.
1. VMware VirtualCenter Server
2. VMware VirtualCenter Management Webservices
3. VMware vSphere Profile-Driven Storage Service
2. Change ODBC connection from SQL authenticated to Windows Integrated.
3. Open Registry and go this path: HKLM/Software/VMware, Inc/VMware VirtualCenter/DB
1. Blank out entries for 2 and 3 (SQL username and crypted password)
4. Modify vcdb.properties file to enable integrated authentication. (Assuming you are using MSSQL)
1. vcdb.properties file is normally located under C:\programdata\VMware\VMware VirtualCenter\
• usevcdb=true
• url=jdbc:sqlserver://YourSQLServerName\\SQLServerInstanceNameifApplicable;databaseName\=YourvCenterDB;integratedSecurity\=true
• dbtype=mssql
• driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
• By not changing the vcdb.properties, you may end up w/ errors for the License Services and vCenter Storage Monitoring Service.
• vCenter Storage Monitoring Service: Service initialization failed.
• License Services: Unable to get license usage data
• etc.
5. Start vCenter services or update vCenter @ this point.

Errors:

sqlstate 08001 Server Error 0

Microsoft SQL Server Native Client Version 10.50.1600

Running connectivity tests...

Attempting connection
[Microsoft][SQL Server Native Client 10.0]Unable to complete login process due to delay in opening server connection

TESTS FAILED!