Virtually Jason

Does your VCenter run on an Oracle backend?  Has that Oracle server ever gone down unexpectedly and, even after the DBA swears it’s back up (and your ODBC connection tests successfully), your VCenter process continues to refuse to start?  You too?  Here’s some details about the situation that I experienced and how we got around it.  First, the identifying information: If you look on your VCenter server in C:\ProgramData\VMware\VMware VirtualCenter\Logs, you will see a lot of log files.  The VPXD-### log files are the ones that I looked at (the most recent one will be a .log file, the others are compressed tar.gz files that can be opened in Windows with 7-Zip , amongst other tools).  If your VCenter service is refusing to start but your ODBC Test Connection is successful, take a look at those files.  I found the following interesting errors in mine: [Vdb::LockRepositoryHelper] SQLExecDirect failed… …Failed to Lock vCenter Repository!!... Unable to get exclusive access to vCenter

ThinApps occasionally require some special manipulations to get working correctly.  One of the most common issues that I’ve seen with otherwise working ThinApp packages is a failure to close correctly.  Sometimes, even after a ThinApp is closed, a process will be left running that might keep the sandbox undesirably locked or cause issues with re-execution.  An easy way to resolve that issue is with a ThinApp Script. These scripts can be used to solve all sorts of issues.  A ThinApp Script is just a VBS script that runs at one of four specified points in a ThinApp’s execution.  The vbs script can be named anything, but should be placed as a sibling with the package.ini file (you only get one vbs file though a script can call another script ad infinitum), in the root of the package.  The vbs script will be automatically baked into the package, and each of 4 optional functions will be executed at the appropriate time.  Those functions are as follows: The OnFirstSandboxOwner func

Several months ago I ran into that issue with accidentally rebooting a server after changing the “active” partition and ending up with a nonbootable system.  We solved it with a linux boot CD (not unlike Trinity , although the one we used was specifically oriented towards disk management), but I’ve just learned that there are Microsoft tools that could do the same thing.  What we were unable to find at the time is DaRT .  That’s Microsoft’s Diagnostics and Recovery Toolkit.  As the name informs, it’s a pretty sweet suite of tools that can be used to diagnose and recover from a variety of Windows problems.  Here’s a list of some cool use cases: Reset a local administrator password Edit the local Registry Restore deleted files (assuming those sectors haven’t been overwritten) Securely delete a partition or drive Open Computer Management (including Disk Management, which is what I needed back then!) Copy files to/from the system with Explorer and network access Remove Windows