Sunday, July 20, 2014

SQL 2000 Service not starting after P2V / VMware tool Install or Update - SQL 2000 - An error 1053 - (the service did not respond to the start or control request in a timely fashion) occurred while performing this service operation on the MSSQLServer service

SQL 2000 Service not starting after P2V / VMware tool Install or Update -
An error 1053 - (the service did not respond to the start or control request in a timely fashion) occurred while performing this service operation on the MSSQLServer service.
Error 1053: The service did not respond to the start or control request in a timely fashion.













I have faced this issue a couple of times. When you get this error, usually you need to check for Service Accounts, try to turn on "Interact With Desktop" etc.
But in this case,
1) Service was working fine on a physical server. After P2V, it is not starting on VM
2) Service was working fine on a VM, and it failed after recent VMware tool upgrade/change. 
Fix
All that you need to do is to make sure that you have the below two DLLs 
msvcr71.dll 
msvcp71.dll
They should be be present under %systemroot%\system32 
If not, you can copy these DLLs from another server running same SQL version, or restore them from a backup. It is noticed that VMware tools sometimes mess up these two DLLs, which make SQL to fail. 

All the best! 
R.Hari

Friday, July 18, 2014

Moving vCenter Server Databases to a different SQL Server / SQL Instance

Assuming that you have documented below mentioned details from Old vCenter Install
1) vCenter and Update Manager Database user passwords
2) RSA_User and RSA_Admin passwords
3) SSO Master Password
Stage 1) - Backup and Restore Databases
  • Stop vCenter Single Sign On,VMware vCenter Inventory ServiceVMware VirtualCenter ServerVMware VirtualCenter Management WebservicesVMware vSphere Update Manager Service and VMware vSphere Web Client.
  • Backup vCenter, Update Manager and RSA Databases and restore in new DB server.
  • Create vCenter, Update Manager and RSA_User and RSA_DBA Users with same passwords on new DB server.
  • Assign Same permissions for users
Stage 2) - Recreate Agent Jobs
  • Open the below location
          vCenter Server 4.x: C:\Program Files\VMware\Infrastructure\VirtualCenter Server\sql
          vCenter Server 5.x: C:\Program Files\VMware\Infrastructure\VirtualCenter Server\sql
  • Copy below mentioned files to a new folder on vCenter server/new SQL Server.
         job_schedule1_mssql.sql
         job_schedule2_mssql.sql
         job_schedule3_mssql.sql
         job_dbm_performance_data_mssql.sql
         job_cleanup_events_mssql.sql
         job_property_bulletin_mssql.sql
         job_topn_past_day_mssql.sql
         job_topn_past_month_mssql.sql
         job_topn_past_week_mssql.sql
         job_topn_past_year_mssql.sql
  • Open job_schedule1_mssql.sql using notepad and copy script
  • On the new SQL server, right click on vCenter Server Database > New Query > Paste the copied script and execute the copied script 
NOTE: Please double check and make sure that you have VCenter server database selected in the Database list and not Master.








  • Repete the same for all the scripts.
  • Once all three jobs are created, navigate to SQL Server Agent and Refresh to see new Jobs created. 
  • Right-click Past Day stats rollup, click Properties.
  • Ensure the owner of the job is the same database login used by VirtualCenter to connect to the database.
  • Repete the same for Past Month stats rollup and Past Week stats rollup.
Stage 3) - Re-pointing SSO Service to the new SQL server
  • Open SSO Install DIR. By default it is C:\Program Files\VMware\Infrastructure\SSOServer and Navigate to \utils
  • Open a command prompt as administrator and run below mentioned command 
       CD C:\Program Files\VMware\Infrastructure\SSOServer\utils
       ssocli configure-riat -a configure-db --database-host <NEW_DBServer_NAME/IP> --database-port <New_DBServer_Port> -m <SSOServerMasterPassword>

  • Open C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes
  • Open config file with NotePad
  • Check port number in the URL and DB Server Name at the last line. 
  • Save the file and exit
  • SSO Service is good to start now!
Stage 4) - Re-pointing vCenter Server to new DB Server
  • Start > Run and "Odbcad32.exe"
  • Under System DSN, Change DB Server settings and Save it.
  • Start VMware VirtualCenter Server Service!
Stage 5) - Re-pointing Update Manager Service to the new SQL server
  • Start > Run and "%systemdrive%\Windows\SysWoW64\Odbcad32.exe"
  • Under System DSN, Change DB Server settings and Save it.
  • Start VMware vSphere Update Manager Service!
If all services are started, reboot vCenter so that all the services are restarted once fresh. 
Disable Agent jobs and Databases on old server, you can probably keep them for a couple of days and then to a cleanup. 

Thank you!
R.Hari

Assuming that you have documented below mentioned details from Old vCenter Install
1) Vcenter and Update Manager Database user passwords
2) RSA_User and RSA_Admin passwords
3) SSO Master Password


Stage1) - Move Databases
Stop vCenter Single Sign On, VMware vCenter Inventory Service, VMware VirtualCenter Server, VMware VirtualCenter Management Webservices, VMware vSphere Update Manager Service and VMware vSphere Web Client.
Backup Vcenter, Update Manager and RSA Databases and restore in new DB server.
Create Vcenter, Update Manager and RSA User and RSA DBA Users with Same passwords on new DB server.
Assign Same permissions for users

Stage2) - Recreate Agent Jobs
Open the below location
vCenter Server 4.x: C:\Program Files\VMware\Infrastructure\VirtualCenter Server\sql
vCenter Server 5.x: C:\Program Files\VMware\Infrastructure\VirtualCenter Server\sql

Copy below mentioned files to a new folder
job_schedule1_mssql.sql 
job_schedule2_mssql.sql
job_schedule3_mssql.sql
job_dbm_performance_data_mssql.sql
job_cleanup_events_mssql.sql
job_property_bulletin_mssql.sql
job_topn_past_day_mssql.sql
job_topn_past_month_mssql.sql
job_topn_past_week_mssql.sql
job_topn_past_year_mssql.sql

Open job_schedule1_mssql.sql using notepad and copy script
On the new SQL server, open Vcenter Server Database and Open New Queiry and execute the copied script 
NOTE: Please double check and make sure that you have VCenter server database selected in the Database list and not Master.
Repete the same for all the scripts.

After all three jobs are created, navigate to SQL Server Agent and Refresh to see new Jobs created. 
Right-click Past Day stats rollup, click Properties. Ensure the owner of the job is the same database login used by VirtualCenter to connect to the database.
Repete the same for Past Month stats rollup and Past Week stats rollup.

Stage3) - Repointing SSO Service to the new SQL server
Open SSO Install DIR. By default it is C:\Program Files\VMware\Infrastructure\SSOServer  and Navigate to \utils
Open a command prompt as administrator
CD C:\Program Files\VMware\Infrastructure\SSOServer\utils
ssocli configure-riat -a configure-db --database-host <NEW_DBServer_NAME/IP> --database-port <New_DBServer_Port> -m <SSOServerMasterPassword>

Executing action: 'configure-db'

Updating Database configuration
Generating HA node package

Successfully executed action: 'configure-db'

Open C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes
Open config file with NotePad
Check port number in the URL and DB Server Name at the last line. 
Save the file and exit
Try to start SSO Service.

Stage4) - Repointing vCenter Server to new DB Server
Start > Run and  "Odbcad32.exe"
Under System DSN, Change DB Server settings and Save it.

Start VMware VirtualCenter Server

Stage5) - Repointing Update Manager Service to the new SQL server

Start > Run and  "%systemdrive%\Windows\SysWoW64\Odbcad32.exe"
Under System DSN, Change DB Server settings and Save it.

Start VMware vSphere Update Manager

If all services are started, reboot vCenter so that all the services are restared once fresh. 

Monday, July 14, 2014

Veeam backup error “Error: Failed to connect to guest agent. Errors: ‘Cannot connect to the host’s administrative share” / Access Denied when accessing Admin Shares (\\IPaddress\C$)

If your Windows Server 2008 box is in a WorkGroup and you require access to one of the admin shares, it can be a little more complicated than with Server 2003.
I had to setup a Veeam backup job for backing up a VM running Windows 2008 in WorkGroup. Initial backup job with default settings went well and I had the enabled “Application Aware Image Processing” and “Guest File System Indexing”. For this I had setup a local admin account on Windows 2008 and provided the credentials in Veeam backup job. Job failed on the test run with below error
'ServerHostName' Error: Failed to connect to guest agent. Errors: 'Cannot connect to the host's administrative share. Host: [10.0.0.11]. Account: []. Win32 error:Logon failure: unknown user name or bad password. Code: 1326 '
10.0.0.11 is the Server IP and I tried to access \\10.0.0.11\C$ and I got the windows asking for credentials. With the local admin account created and it worked from same server. When I tried remotely from Backup server, It was showing “Access Denied” error when provided user and password. It was quiet surprising because it is a local admin use and that’s the issue then.
Access Denied error eliminated possible causes like
1)      “Server” Service not running (should have thrown “The specified network name no longer available” error)
2)      File and Pinter sharing disabled on NIC properties
3)       Secpol.msc -> user rights assignment -> “Access this computer from network” and  “Deny Access to this computer from network” (error should be something like “Logon failures: the user has not been granted the requested login type at this computer” error.
Also checked few things like Start -> Run -> fsmgmt.msc and Administrative shared looks good here
Then finally the fix
Issue was with UAC and here is a KB articles http://support.microsoft.com/kb/951016 and http://support.microsoft.com/kb/942817 talks about this issue in Vista.
So it is a security feature and From the KB Article:  “How UAC remote restrictions work: To better protect those users who are members of the local Administrators group, we implement UAC restrictions on the network. This mechanism helps prevent against "loopback" attacks. This mechanism also helps prevent local malicious software from running remotely with administrative rights.”
So please be sure about the risks.
 So what I had to do was -
1)      Right Click on PowerShell Icon in the system tray
2)      Right click on “Windows PowerShell”
3)      Run as Administrator 










4)      Execute below command
New-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -name "LocalAccountTokenFilterPolicy" -value "1" -propertyType dword

Thanks!
R.Hari

Friday, July 11, 2014

Reconfigure network after P2V – Message “The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter”

I am sure that the below message is pretty familiar to you if you are working on P2V migrations. Basically, when you try to configure PROD/Mail ip back to the VM after P2V, you will come across this message.  
"The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter"
Message says that the earlier NIC with this IP is still there in the VM, but not visible as it is not attached to the Hardware/OS currently. Windows shows the above message to remind you that there was a NIC earlier with the same IP.  I have seen this message after VMware hardware upgrade also..
It is always better to do clean up post a P2V, instead of just skipping this message. Below mentioned the simple, two line step, which you can run on a VM after P2V to clean up these old NIC card devices and associated drives as we no longer need them.
1) Go to Start > Run
2) Type "cmd" and Enter
3) execute below mentioned commands
set devmgr_show_nonpresent_devices=1
start devmgmt.msc
4) Run both the commands in the same command prompt, because the first command actually forces device manager to start with the ability to see non-present devices when second command is executed.
5) Once Device Manager is open, click View > Show Hidden Devices.
6) Expand the Network Adapters and here you will see the old NICs which is displayed as grayed out. 
7) You can remove them one by one. You can also click the check box to remove old drivers, if there is an option. 
8) Now you can configure the new NIC with the IP.

Thank you!
RHari.