This week, I would like to talk about the Windows agent available in Log Insight 2.0. First up, I would like to cover how to deploy the Window Agent on your Window’s VMs. Please note the Windows agent support Windows desktop versions Vista and newer and server versions 2008 and newer.
I have been spending a lot of time working with vCAC logs files as of late and what I realized is that vCAC is made up of a lot of components and a lot of different log files. Unfortunately, vCAC does not support setting a remote syslog destination to forward all vCAC logs within the GUI today. As such, I would like to cover where all the log files are located and more importantly how you can forward them to a remote syslog destination like Log Insight.
UPDATE: This post is based on vCAC 6.0, if you are running vRA 6.1 or newer, please be sure to see my updated post here.
Someone recently asked me if Microsoft’s Log Parser application could be used as a syslog agent. To be honest, I had not heard of the application so I looked it up and tried it out. This post is a result of what I learned.
In order to send events from a Windows device to a remote syslog server like Log Insight, you need a syslog agent. Windows does not natively support syslog. The good news is that several syslog agents for Windows exist. I would like to cover my considerations and recommendations for a syslog agent on Windows.
UPDATE: As of Log Insight 2.0, Log Insight offers a free Windows agent that supports the syslog protocol and Log Insight’s ingestion API. For more information see these posts.
If you receive the error message “Remote Desktop Connection cannot verify the identity of the computer that you want to connect to.” and do not get a Connect button then the domain information being passed cannot be resolved or is not correct. To fix the issue on the Mac, go to RDC – Preferences…, ensure Domain: is blank or set correctly, and then try to connect again.
While testing a vCenter Heartbeat (vCHB) installation, I cloned the Windows VM used for vCenter Server, but did not use guest customization as the vCHB directions stated not to. Since guest customization was not selected, sysprep was not run on the new Windows system.
Once the clone was complete, I followed the directions and disconnected the vNICs. Next, I powered the system up and changed the IPs. Finally, I reconnected the vNICs. I tried a ping to an outside address and to an IP configured on the VM and received:
PING: transmit failed, error code 1232.
This appears to be an old problem that keeps popping up, but I just experienced it for the first time. I was tasked with deploying 20 Windows VMs (more on this in a later post) for a project. I did so via templates and once the systems came up, I set the appropriate IP addresses as well as other configuration information. The last step was to reboot the VMs. After reboot about half of the VMs were responsive to ICMP and RDP while the other half were not.
To my surprise, upon checking the network configuration on the hosts that were unresponsive from the console, I found the default gateway was not set. It was a long day at work (>12 hours) and I thought I just missed something (more on why I did not automate this task in the later post as well). I set the default gateway, rebooted, and the same problem occurred.
Why was the default gateway configuration being lost on reboot and how can it be fixed?
So I installed a Windows XP VM the other day with a corporate ISO file. The initial login screen showed the administrator account and another corporate specific account. I logged in as administrator and applied the latest patches. Upon rebooting the system, only the corporate specific account was available. I was unable to find a way to log in as administrator and I did not know the password for the corporate specific account.
How could I log in as administrator?
The other day, I created a Windows 2008 VM and installed VMware Tools on it. One thing I noticed upon reboot was that the console was extremely sluggish. Upon thinking about it, I realized that unlike in Windows 2003 VMware Tools did not prompt me to adjust the hardware acceleration for the display. As such, I decided to check and ensure it was properly set to full. As I expected, it was not. Upon setting it to full and rebooting the VM the console became much more responsive. (As a side note, if you want to adjust the hardware acceleration and have it take effect without rebooting the VM, change the resolution or the colors before adjusting the hardware acceleration, but do not apply the changes. Next, set the hardware acceleration to full and apply the changes. Finally, you can revert the resolution or colors back to the default setting. Once completed, you should notice the console is much more responsive without rebooting the VM, though you are still prompted to do so.)
I would be remissed if I did not also mention that you should also ensure the “VMware SVGA II” driver is being used. If you see “Standard VGA Display”, go to the properties of the device and select “Update Drive…”.
Today, while working on a Windows jump box I received a Windows error message stating that DCOM had shutdown unexpectedly and as such the computer was going to reboot in 60 seconds. I was not the only person on this jump box so I thought nothing of it. Once the 60 seconds had elapsed, my laptop, and not the jump box, restarted.
While this was weird, I thought nothing of it since I had been experiencing Windows issues with the device for some time. The computer rebooted and I logged back in. I decided to download the latest updates for my computer, but while loading the Windows update site the same error message appeared and after 60 seconds my computer rebooted again.
What was happening?