I came across the following error whilst trying to install Veeam Backup & Replication 11.0.0.837 on Windows Server 2022:
|
1 |
Setup Failed. Installation was interrupted before application could be installed. You need to restart the installer to try again… |
Installation logs are saved under:
|
1 |
C:\ProgramData\Veeam\Setup\Temp |
in BackupSuite_DD_MM_YYY_HH_MM_SS.txt format but they do not necessarily give away the reason for the setup failure:
Continue reading
For absolute ages now we have been crying out loud to have some sort of serial access to Azure VM’s. Now, this request has been fulfilled and the Special Administrative Console (SAC) is available in preview for Windows and Linux guests! Windows images on Azure do not have Special Administrative Console (SAC) enabled by default (see below). SAC is supported on server versions of Windows but is not available on client versions like Windows 10, Windows 8 or Windows 7 etc.
To enable Serial console for Windows Virtual Machines please use the following steps:
|
1 2 |
bcdedit /ems {current} on bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200 |
To access the SAC head over to Serial console (Preview) item on Azure Portal and get greeted with the following:
How very awesome! 🙂
Recently I have been re-installing my home lab due to the 60 day trial license coming to an end and discovered something odd. During the installation of vCenter 5.5 on Windows Server 2008 R2 SP1 I came across the following error:
|
1 |
Unable to contact Lookup Service. Check vm_ssoreg.log in the system temporary folder for more details. Search the VMware Knowledge Base (http://kb.vmware.com) for "Error 29102" for more information. |
The solution was rather simple but not straight forward to work out initially. My internal network ID for VMware hosts is 10.10.0.0/24 but what I was missing is the corresponding rDNS zone in my DNS (reverse). The minute I have created 0.10.10.in-addr-arpa the error went away. What makes this even stranger is the fact I have to redo my lab every 60 days and this is the first time this error has come up!
Don’t we all just love to see everything in green/healthy/hunky dory state when it comes to service availability? I know I am definitely one of those that do (OCD and all that..)
If you’re running VMware vCenter 5.5 Update 2 you might find, upon checking, that VMware vCenter Storage Monitoring Service has an alert with a message stating that Service Initialization Failed:
|
1 |
VMware vCenter 5.5 Update 2 Service Health displays Storage Monitoring Service “service_initialization_failed” |
I have been using the free version of Veeam Endpoint Backup (VEB) product since it was first released and it works wonders. Really good software that just keeps getting better and better. You can not only backup desktop and laptops but also VMware virtual machines with PCI pass-through devices which Veeam Backup & Replication 9 cannot properly backup since snapshots are not allowed when PCI-e devices are in use. Another good use case for VEB is the ability to backup Hyper-V hosts themselves. I have a large number of Hyper-V boxes dotted around and although I use Veeam Backup & Replication to back up the virtual machines I still need some sort of backup for the hosts. VEB fills this gap perfectly and in the unlikely event of a disaster, I would use VEB to restore the host (C drive i.e. the OS) and Veeam B&R to get my virtual machines back (D drive where the VMs sit). This setup works really well and I already had to use it once!
One thing however that didn’t quite make to the GUI yet is the slightly annoying fact when you point the backups to SMB share and change the hostname of the source machine the backup name doesn’t reflect the new hostname within the share. In my example my Core i3 test bench used to be called DESKTOP-9H9LL2J but now I have changed its name to SPN-TESTB-01 to comply with my standard naming convention. In an ideal world, the backup folder should also change its name but that’s not the case. Here are some examples, hostname has been clearly changed to DESKTOP-9H9LL2J:
Pretty silly thing to do really – I have left the default site name when installing SRM 5.8 so it has FQDN of my vCenter box instead of a proper name:
From vSphere Web Client point of view having FQDN in there is not ideal as well as introducing confusion which site is which (live vs. recovery):
To get the site name changed we need to edit vmware-dr.xml which lives (by default) in the following location:
I have been struggling to fix this rather weird disk space issue for quite some time now. Basically, underlying thin provisioned disk on vSphere 5.5 was extended by additional 5GB (from 125 to 130GB) and expanded using Disk Management from within the OS as per the normal routine. No problems thus far BUT Explorer in Windows Server 2012 R2 was not reporting the increased space and was still showing the 125GB total size! How odd. Here is the screenshot for illustration purposes showing Disk Management and Windows Explorer both reporting different values!
I must have done the disk space increase from vSphere and extension from the guest OS hundreds of times and never had any real issues. There are tons of potential solutions to this problem, quite a few posted here:
CrashPlan woes continue!
This error is from an earlier version of the CrashPlan software i.e. 4.3.0 which one of my customers is still running. So here it is – fully appreciate you won’t be able to read native Polish language but the error states that:
Monday morning eh? It surely is!
Trying to install CrashPlan 4.4.1 (CrashPlan-x64_4.4.1_Win.exe) is proving to be a lot more hassle than it should..
Error messages shortly after kicking off the .msi installation:
Cleaning up NetApp SnapManager for Virtual Infrastructure snapshots in VMware vSphere can be a pain if you have large number of VMs being backed up by SMVI. In my case there are snapshots that are consistently left behind like so:
which just pile up as the days go on. I think this is some sort of bug in either vSphere API or the way NetApp handles snapshotting during the backup window.
To have these snapshots cleared up after the backup jobs run I have written the following PowerShell script to deal with the situation: