HxD - Freeware Hex Editor and Disk Editor
http://mh-nexus.de/en/hxd/
Want to work for VMware IT in Colorado Springs, CO? We need a new Sr. Lab Engineer. Looking for someone with good VMware knowledge and solid networking and storage skills. Come join us! http://bit.ly/TUitg5
One of the many useful features of VMware vCM is that you can audit local accounts for security risks and then through various actions remediate those risks. In this example I have discovered on my Windows machines that I have a single admin account that does not have the “Password Required” attribute set and want to disable the account. To get to this point I have collected “Accounts” data against my Windows machines.
Next I navigate to Security > Local Accounts and am greeted with the below graph. (Hint, you can skip the graph and go straight to the data grid if you hold down CTRL when you click on the “Local Accounts” button.) It is on this screen that I see that one of my admin accounts does not have a password enabled. Let’s click on it to get some more details.
Next I see all the information on the account. Also if you hover over that first icon on the left you will notice that it says the account is currently enabled. Not for long… Click on “Edit Properties”.
Your account is already pre-selected for change…
Select the Account Attribute…
… and say that you want it to be disabled…
Next run the action or schedule it for later.
Once that job completes we need to recollect from that machine to get the current status of the account information. To do that start a new collection and go grab the “Accounts” information.
Perfect, if you notice on the top graph 1 account now shows as disabled. Let’s drill into the admin account that does not require a password. Hopefully it will show up as disabled.
Looking at the first icon we see that it is indeed disabled. But let’s go one step further, lets use vCM to rename the account and change the password.
Next we go through the “Change Password” and “Rename Account” wizards and supply new values that we want. After the changes are complete and we recollect we can see that the password age is now 0 days, the account name has been changed and the account is disabled.
This little tutorial demonstrates a couple tasks that are really important and easily implemented.
1. Auditing Accounts (also includes password age, failed password attempts, date of last login)
2. Automatically changing passwords for Local Accounts (Yes, you can change multiple passwords at the same time.)
3. Renaming Local Accounts
Be pretty cool if you could do that all automatically right? Well, stay tuned for a later post on using vCM Compliance Rules to automate your compliance and remediation.
1. Static Content
2. Dynamic Content
3. Directory Browsing
4. HTTP Errors
5. HTTP Redirection
1. ASP.NET2. .Net Extensibility3. ASP4. ISAPI Extensions5. ISAPI Filters6. Server Side Includes
1. HTTP Logging2. Logging Tools3. Request Monitor4. Tracing
Just install them all.
1. Static Content Compression2. Dynamic Content Compression
1. IIS Management Console2. IIS Management Scripts and Tools
1. Database Engine Services
2. Full-Text Search – optional
3. Reporting Services
4. Client Tools Connectivity
5. Management Tools – Basic
6. Management Tools – Complete
If you have ever used vCenter Operations Manager with the non-web client you are used to having to create a new IP Pool before the vAPP will deploy. This was kind of a pain and apparently now using the NextGen Web client you don’t need to do that any more. The warning message is still in the vAPP but you can just ignore it because what happens behind the scenes is the Web Client will automatically create the IP Pool for you. Actually taking that one step further if you do create the IP Pool before deploying the vAPP your deployment will fail. Here’s the detailed why:
1. Create a new IP Pool which is now called a “Network Protocol Profile” under the Datacenter level where you want vCOps to live. I called mine vCOps since that is all it will be doing.
2. Next configure your IPv4 options. This is where it gets tricky. I want to manually specify what IP the Analytics and UI VMs get and in the past I just built a new pool and when I deployed the OVF I just specified the IPs for each VM. Let’s see what happens when I do that now… I’m going to create a pool of 2 IPs, one for each VM just like with the old thick client.
3. Next I specify Static – Manual IP because I am going to add the records to DNS.
4. And I specify what VM should get what IP. At this point I get an error message that says “The IP Address cannot be in the range reserved for the IP Pool of the network <Network Name>”. Huh, I thought that was the entire idea behind IP Pools…
If I go back a screen and change my IP Allocation setting to “Transient – IP Pool” then I won’t be prompted for what VM get’s what IP and as the vAPP is powered up you have a 50/50 chance that your VMs have the IPs that you want. Not what I am looking for…
5. For this to work I had to go back to my original “Network Protocol Profile” and give the IP Pool Range a single random IP that vCOps will NOT be using (too bad I can’t leave it blank) or uncheck the “Enable IP Pool” which seems very counter intuitive. Once I did that I was able to manually specify what IPs each vCOps VM should have. Again, totally counter intuitive…
At this point I realized that the message in the vAPP that tells you that you need to create an IP Pool is completely erroneous. If you deploy the vAPP without creating an IP Pool the deployment will succeed. The reason it succeeds is that it automatically creates a new IP Pool that looks like the below, one that shows the IP Pool is disabled….
As you start to use ESXi AutoDeploy more you will run into occasions where you want to look behind the scenes and see what is going on. There are a couple ways to do so:
1. In vCenter click on the “Auto Deploy” button under Administration and hit “Download AutoDeploy Log Files”. This will give you a ZIP file of the logs on the AutoDeploy Server and provides lots of information on what is going on or what might be broken.
2. Go to https://<serverIP>:6501/vmw/rbd/host/
This will bring up a list of all the hosts that have called into the AutoDeploy Server. From there you can click on the host and get more information:
From this screen you can also go to the Get gPXE Configuration which shows you your boot information (including Host Profile and Image Profile being used,) or the Get boot.cfg which shows you what appears to be the actual download of the operating system files to the server.