I have been using System Center Configuration Manager to deploy software to clients for a while now but I recently had a requirement to control a client remotely. In order to control clients using the SCCM Remote Tools feature, some ports needed to be opened on the client in the Windows firewall.
I was trying to deploy some software to a Windows XP SP3 client when I noticed that there seemed to be an issue with network connectivity. For some reason the client hadn't downloaded and installed any software hat had been pushed to it via SCCM. On the off chance, I happened to check the computer name in 'System Properties' (to see who the computer belonged to) and I noticed that the buttons for 'Network ID' and 'Change' were greyed out.
I wanted to install some DRAC 5 cards into each of my Dell PowerEdge 2900 VMware ESX hosts, so I decided to VMotion off the Virtual Machines onto other hosts in the cluster before shutting down the node. The first Virtual Machine migrated without a problem but when I tried a second I received an error stating the there was a CPU incompatibility between the host and the Virtual Machine.
Every now and then I need to resize (usually extend/enlarge) a disk attached to a Virtual Machine. I have tried several methods to do this over the years (including combinations of VMware Converter, third party partition manager apps, diskpart etc) but none have been as efficient as the method I discovered during recent VMware training for my VCP4 exam.
At work, people were using VPN to access their email out of the office, but I have always thought that logging into a corporate network via VPN for most users is an extra hassle that they could probably do without. I had considered setting up RPC over HTTPS for Exchange 2003 but during a meeting regarding disaster recovery it became evident it was actually now a necessity. So, after configuring the server for RPC-HTTPS I had the small problem of deploying the settings to Outlook clients en masse.
Post the upgrade of a VMware infrastructure from ESX 3.5 to vSphere 4, I encountered an issue when upgrading the Virtual Machines. I had already installed the latest VMware tools and after upgrading the hardware from version 4 to version 7 I wanted to remove the standard NIC attached to each Virtual Machine and attach the new vmxnet3 NIC.
I had a problem the other day when I went to logon to a server using RDP and the text fields where you enter your username and password were black! I typed in my credentials anyway and found that I could still logon to the server. After this there seemed to be no other issues.
I have just tried to open a file with a .chm extension on a computer running Windows Vista. The file is located on my desktop yet when I tried to open it only the table of contents would display and not the actual pages containing any content. Instead I was presented with a screen that said: 'Navigation to the webpage was cancelled'.
I am frequently asked to allow access to our servers for 3rd party company usually trying to fix some sort of software issue in their application (the typical scenario.) Most companies tend to use applications such as GoToMeeting or Live Meeting which Iâ€™ve never really been in favour of. Recently I was told that in order for a new implementation to commence I would have to give a company VPN access to our network and Remote Desktop Connections onto the relevant servers.
I have been using VMware ESX for quite a while now and while the technology is a brilliant concept every now and then I find a small problem or pitfall that always seems to bug me! I have a 3 node ESX cluster that I implemented in my work office and was working on configuring a 5 node cluster when I noticed an issue with VCenter (formally Virtual Center) that had occurred in both environments. It seemed that for no apparent reason when I rebooted the server running VCenter the 'VMware VirtualCenter Server' (or 'vpxd' windows service name) service failed to start. This was kind of annoying, more so knowing that the new 5 node setup was going to a datacenter where people would be less likely to spot that it hadn't started after the reboot of the server running VCenter!