almost daily tech ramblings
Just a n FYI that the following Microsoft products will be end of life “relatively soon”
July 9, 2019 – MS SQL Server 2008/ 2008 R2 – July 9, 2019
January 14, 2020 – MS Windows Server 2008 / 2008 R2
After these dates, extended support will end and the affected products will no longer have security or reliability patches.
You will probably be able to still run them, but I would not suggest it.
Last year introduced PDQ as way to easily deploy applications to desktops. In the past, applications were either installed in the master clone, thinapp’d or manually installed by remotely connecting to the VM and installing it locally.
This is where I did a POC and proved that this was a time saver and pretty much fool proof.
In the last few months I started looking at using PDQ to install Windows patches. Preliminary tests showed that it worked well. I did look at WSUS, but was limited in terms of scheduling, and without using something like SCCM or SCOM, it would be very hard to manage. I also did not want to put up infrastructure just for patching.
PDQ pushes out Windows patches just like any other application, connects to the target, installs, and reboots, if you choose to. DONE.
However, there was no easy way to snapshot the VM. I came up with a PowerCLI script attached as a Pre-Step, however, I soon discovered that the PowerCLI script also ran on the target computer, and not on the source. One solution presented was installing PowerCLI on all server VMs. Tossed that idea out quickly as I didn’t want to install PowerCLI on all VMs, and with how the script worked, a snapshots of all VMs would occur on all VMs. So if I had 10 VMs in the script, the script would run on all 10 VMs, give me 100 snaps in total.
After some brainstorming, I decided to have the script run as scheduled task. If I had the patching occur at 2AM, I could have the script run at 1:58AM. Early testing showed that this worked just as expected. BINGO!
Only thing I need to make sure of, is to update the server list, so the VMs scheduled for patching gets snapped.
So essentially, have a scheduled task run the script 2 minutes before patch time, and then have the patch schedule run.
Hope this helps other people facing the same or similar problem
The other day, I was asked how to change the NTP Server on a Windows Server 2008 R2 VM. I responded with a dumbfounded look, and replied with, “You don’t, the Server talks back with an AD server that with PDC Emulator role and syncs with that server…” Of course, my storage guy only asked me because his Unisphere VM was almost 2 minutes off. So naturally I took a look and discovered, that it was not syncing at all.
Query the current time settings always pointed back to
Local CMOS Clock
which is not a good thing.
Further investigation showed that the registry settings for W32time was incorrectly modified.
So after much Googling, I ended up resetting the Windows Time:
net stop w32time
W32tm /unregister
w32tm /register
net start w32time
Then for good measure, I configured Windows Time is use the forest time hierarchy:
w32tm /config /syncfromflags:domhier /update /reliable:no
w32tm /resync /rediscover
net stop w32time && net start w32time
After a few minutes, the Windows Time was now sync’d up with the AD Server.
The other day I need to “mass deploy” an application to our users at the hotels. Normally, pushing applications using PDQ is straightforward, however, the installation needed some user inputs such as server name, username and install feature. Luckily, the installer was an MSI, and was able to create a transforms file to automatically answer those questions.
Found this simple application, Transforms Creator
The application is fairly simple, after installing the Transforms Creator, you would find the MSI in question, right click it and select Create Transforms. The MSI will then simulate an install, answer all the questions needed, once you’re done, an MST will be generated.
Tested it out, and it worked exactly as I needed.
I did run into some issue using TRANSFORMS in PDQ. This was merely a user issue and not knowing how to do this rather than technical. So for future reference, when creating a package in PDQ, you’ll need to the following settings in the Edit Package dialog box:
Parameters: TRANSFORMS=transforms_package.mst
and the ensure that you check “Include Entire Directory” otherwise, you’ll get an error message saying:
“This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.”
My storage engineer recently approached me about a couple of VMs that were failing to backup because it could not quiesce. We were seeing:
My storage engineer recently approached me about a couple of VMs that were failing to backup because it could not quiesce. We were seeing:
“An error occurred while saving the snapshot: Failed to quiesce the virtual machine.”
An open call to EMC said to run an extended Snapshot, however, that is only available starting with vSphere 6.5. Despite that, running a manual snapshot using the vCenter MOB was successful.
Running scheduled and unscheduled backups failed with the same message.
However, after digging into the logs, I saw a very specific error message:
The guest OS has reported an error during quiescing. The error code was: 5 The error message was: ‘VssSyncStart’ operation failed: IDispatch error #8472 (0x80042318)
A quick search shows that this can be resolved by a number of ways, re-registering the VSS Components and re-configure VMTools.
for my purposes, re-registering the VSS Components did the trick. Instead of running each of the following commands separately, I put them into a batch script.
cd /d %windir%\system32 net stop vss net stop swprv regsvr32 /s ole32.dll regsvr32 /s oleaut32.dll regsvr32 /s vss_ps.dll vssvc /register regsvr32 /s /i swprv.dll regsvr32 /s /i eventcls.dll regsvr32 /s es.dll regsvr32 /s stdprov.dll regsvr32 /s vssui.dll regsvr32 /s msxml.dll regsvr32 /s msxml3.dll regsvr32 /s msxml4.dll vssvc /register net start swprv net start vss
I’ve recently built a new W7 VM for AppVolume provisioning, however, when trying to install windows updates, I get the following
For whatever reason, my new Windows build couldn’t contact the MS Windows Update servers. After some Googling, I ran into a post saying to add windowsupdate.microsoft.com to the list of trusted sites. After putting that in, I was able to update the OS.
The last few months I’ve had some issues installing certain applications. Some applications would be looking for the msi in the Windows temp directory, in one instance, VAMT would fail with Error 1651.
Well, I’ve finally resolved the issue with the following:
According to the website, the following is fixed:
To fix my issues I would select the application that is giving me a problem, select uninstall, and then re-run the installation.
very strange situation today. I performed a single disk svMotion on my vCenter VM which also had 4 mapped raw LUNs. However, after a reboot, the VM never came back on line saying that it cannot find the boot device.
after much tinkering around, I performed the following to get my vCenter back:
Attached Server 2012 ISO to the VM.
Launched Repair
From the command prompt
diskpart
select disk 0
select partition 2 (this will depend on your windows installation, if you remember it)
active
exit
then the following commands
bcdboot c:windows
bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd
bootrec /scanos.
reboot…..
🙂
