Wednesday, April 13, 2011

Choosing a network adapter for your virtual machine

Network adapter choices depend on t he version number and guest operating system running on the virtual machine.


Available Network Adapters
Only those network adapters that are appropriate for the virtual machine you are creating, are available configuration options in the Choose Networks window.
  • Vlance — An emulated version of the AMD 79C970 PCnet32 LANCE NIC, an older 10 Mbps NIC with drivers available in most 32bit guest operating systems except Windows Vista and later. A virtual machine configured with this network adapter can use its network immediately.
  • VMXNET — The VMXNET virtual network adapter has no physical counterpart. VMXNET is optimized for performance in a virtual machine. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET network adapter available.
  • Flexible — The Flexible network adapter identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself and functions as either a Vlance or a VMXNET adapter, depending on which driver initializes it. With VMware Tools installed, the VMXNET driver changes the Vlance adapter to the higher performance VMXNET adapter.
  • E1000 — An emulated version of the Intel 82545EM Gigabit Ethernet NIC. A driver for this NIC is not included with all guest operating systems. Typically Linux versions 2.4.19 and later, Windows XP Professional x64 Edition and later, and Windows Server 2003 (32-bit) and later include the E1000 driver.
  • VMXNET 2 (Enhanced) — The VMXNET 2 adapter is based on the VMXNET adapter but provides some high-performance features commonly used on modern networks, such as jumbo frames and hardware offloads. This virtual network adapter is available only for some guest operating systems on ESX/ESXi 3.5 and later.

    VMXNET 2 is supported only for a limited set of guest operating systems:
    • 32 and 64bit versions of Microsoft Windows 2003 (Enterprise and Datacenter Editions).

      Note: You can use enhanced VMXNET adapters with other versions of the Microsoft Windows 2003 operating system, but a workaround is required to enable the option in VMware Infrastructure (VI) Client or vSphere Client. See
      Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003 (1007195) if Enhanced VMXNET is not offered as an option.
    • 32bit version of Microsoft Windows XP Professional
    • 32 and 64bit versions of Red Hat Enterprise Linux 5.0
    • 32 and 64bit versions of SUSE Linux Enterprise Server 10
    • 64bit versions of Red Hat Enterprise Linux 4.0
    • 64bit versions of Ubuntu Linux
  • VMXNET 3 — The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery.

    VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems:
    • 32 and 64bit versions of Microsoft Windows XP, 2003, 2003 R2, 2008,and 2008 R2.
    • 32 and 64bit versions of Red Hat Enterprise Linux 5.0 and later
    • 32 and 64bit versions of SUSE Linux Enterprise Server 10 and later
    • 32 and 64bit versions of Asianux 3 and later
    • 32 and 64bit versions of Debian 4
    • 32 and 64bit versions of Ubuntu 7.04 and later
    • 32 and 64bit versions of Sun Solaris 10 U4 and later
Notes:
  • Jumbo frames are not supported in Solaris Guest OS with VMXNET 2 or VMXNET 3.
  • Fault Tolerance is not supported on a virtual machine configured with a VMXNET 3 vNIC in vShpere 4.0, but is fully supported on vSphere 4.1.
Adapter Caveats
This section discusses some potential problems you might have.
  • Migrating virtual machines that use enhanced vmxnet
    VMXNET 2 is new with ESX 3.5 virtual machines configured to have VMXNET 2 adapters cannot migrate to earlier ESX hosts, even though virtual machines can usually migrate freely between ESX 3.0 and ESX 3.0.x.

    I
    f you must migrate a virtual machine between later and earlier hosts, do not choose VMXNET 2.
  • Upgrading from ESX 2.x to ESX 3.x
    When a virtual hardware upgrade operation transforms a virtual machine created on an ESX 2.x host to an ESX 3.x host, Vlance adapters are automatically upgraded to Flexible. In contrast, VMXNET adapters are not upgraded automatically because most or all Linux guest operating system versions do not reliably preserve network settings when a network adapter is replaced. Because the guest operating system thinks a Flexible adapter is still Vlance, it retains the settings in that case. If the upgrade replace a VMXNET adapter with a Flexible adapter, the guest operating system erroneously discards the settings.
    After the virtual hardware upgrade, the network adapter is still VMXNET, without the fall back compatibility of the Flexible adapter. Just as on the original earlier host, if VMware Tools is uninstalled on the virtual machine, it cannot access its network adapters.
  • Adding virtual disks
    Adding an existing earlier (ESX 2.x) virtual disk to an ESX 3.x virtual machine results in a de-facto downgrade of that virtual machine to ESX 2.x. If you are using ESX 3.x features, such as enhanced VMXNET or Flexible network adapters, the virtual machine becomes inconsistent. When you add an existing ESX 2.x virtual disk to an ESX 3.x machine, immediately use the Upgrade Virtual Hardware command to restore the virtual machine to the ESX 3 version. This problem does not arise when you add earlier virtual disks to an ESX/ESXi 4.0 virtual machine.

    Note: Executing Upgrade Virtual Hardware changes the ESX 2 virtual disk so that it is no longer usable on an ESX 2 virtual machine. Consider making a copy of the disk before you upgrade one of the two copies to ESX 3 format
    .
For more information on guest operating systems, search the VMware Compatibility Guide.

Tuesday, April 12, 2011

Standard ESX networking tasks from command line

As I was looking around in the command line interface (which is pretty new for me) I came around the esxcfg- command set. In particular the commands to manage the NIC’s (part 1) and the vSwitches (part 2) raised my interest. I decided to explore a bit further and write down how to do some standard actions. So here goes for NIC operations…

Listing all NIC’s

esxcfg-nics -l

This commands gives you a nice list of all the available NIC’s and all their properties. Those properties include name, link, speed, duplex and description.

Setting a specific link speed and duplexity of a NIC

The thing I want to do here is set my ‘vmnic3′ (the name I got from my previous command) to a speed of 100Mbps and I want to set it to full duplex. The command to do this is:

esxcfg-nics -s 100 -d full vmnic3

The ‘-s’ parameter defines the speed. This parameter can hold the values 10, 100, 1000 and 10000 respectively defining the speed to 10Mbps, 100Mbps, 1000Mbps and 10000Mbps.
The ‘-d’ parameter defines the duplexity. This parameter can hold the value ‘full’ for full duplex and ‘half’ for half duplex.

Setting link speed and duplexity of a NIC to automatic detection

To set my ‘vmnic3′ back to automatic detection I use the following command:

esxcfg-nics -a vmnic3

The ‘-a’ parameter simply sets the link speed and duplexity of the NIC back to automatic.
I hope this was useful to someone. At least I got better understanding and a little reminder for myself how to do these things. In part 2 I will cover some standard networking tasks considering virtual switches using the command esxcfg-vswitch.

Listing all virtual switches

esxcfg-vswitch -l

This commands gives you a list of all the configured virtual switches with their PortGroups and connected uplinks. Further more a lot of properties are shown about the vSwitches and PortGroups. For vSwitches it shows among other things the name, the uplinks, the number of used ports and the number of configured ports. For PortGroups it shows the PortGroup name, VLAN ID and uplinks.

Add a virtual switch called ‘TestSwitch1′

It’s really simple to add a virtual switch to an ESX server. You simply use the following command:

esxcfg-vswitch -a TestSwitch1

This creates a virtual switch with the name ‘TestSwitch1′. It still has no PortGroups and it has been set with the default amount of configured ports (64). To see all the properties use the command provided earlier to list the virtual switches. If you want to specify the number of configured ports you can use the following command:

esxcfg-vswitch -a TestSwitch1:16

This gives you a virtual switch named ‘TestSwitch1′ with 16 configured ports.

Add a PortGroup to a virtual switch called ‘TestPortGroup1′

Now we want to add a PortGroup to a virtual switch. The following command adds a PortGroup called ‘TestPortGroup1′ to our previously created virtual switch:

esxcfg-vswitch -A TestPortGroup1 TestSwitch1

This will create a PortGroup with VLAN ID 0. Notice that this time we used ‘-A’ to add the PortGroup since ‘-a’ is used for adding virtual switches. When we want to set the VLAN ID of the PortGroup we have to issue a second command. This command will set the VLAN ID of the PortGroup we just created to VLAN ID 2. The parameter ‘-p’ defines the PortGroup and ‘-v’ defines the VLAN ID you want to set it to.

esxcfg-vswitch -p TestPortGroup1 -v 2 TestSwitch1

Add an uplinkto the virtual switch and PortGroup

So now we got a virtual switch and a PortGroup. I guess we would like some connection to the outside world. So when we want to bind a physical NIC to the created PortGroup the thing to do is link the pNIC to the virtual switch and after that we automatically have the link to the PortGroup. First you need to find out what pNIC you want to bind to the virtual switch. You can check the names of the pNIC’s with the command esxcfg-nics -l. Now that we know the name we can bind it to the virtual switch. With the following command I will bind ‘vmnic4′ to the created virtual switch:

esxcfg-vswitch -L vmnic4 TestSwitch1

Notice that the l is a capital L, the normal l is already used for showing the list. Now we have configured the virtual switch correctly and we have a fully functional virtual switch with a virtual machine port group.

Remove a link from the PortGroup and virtual switch

Well first lets undo the links we just binded to the PortGroupand the virtual switch. It’s al pretty straightforward from here. If you managed to make the links it will be just as easy to undo them. The command for disconnecting the pNIC from the virtual switch is:

esxcfg-vswitch -U vmnic4 TestSwitch1

This will unlink ‘vmnic4′ from the virtual switch and the PortGroup. Notice that the ‘-U’ parameter is with a capital U just like the ‘-L’ for linking the pNIC.

Remove a PortGroup from the virtual switch

Removing the PortGroup is really simple. You just take the command you used to create the PortGroup, but instead of the ‘-A’ parameter you use the ‘-D” parameter (all capital). So the command to accomplish a deletion of the PortGroup ‘TestPortGroup1′ from virtual switch ‘TestSwitch1′ is:

esxcfg-vswitch -D TestPortGroup1 TestSwitch1

Now the virtual switch should be empty (if you didn’t do anything else to the virtual switch). There should be no PortGroups and no connected uplinks.

Removing a virtual switch

Now to set everything we have done back to the original state we have to delete the virtual switch we just made. Again this is really simple if you alter  the create command. Just replace the ‘-a’ parameter with ‘-d’. The same as with the PortGroup only this time no capital characters.

esxcfg-vswitch -d TestSwitch1

And now if you list all the virtual switches again this should give you the same picture as at the beginning.

Ofcourse there are lots of things more you can do from command line networking related, but I thought this was the most basic and standard stuff you would want to do. Scott Lowe wrote some articles about more advanced operations like Setting Load Balancing Policies and Modifying a PortGroup using the CLI. I hope this articles were useful for all of you. At least it has given me a nice reference for the future.

Monday, April 11, 2011

Vmware Build Number

 All,

To find the VMware Build no to their appropriate Release or Update. Follow the link below.

VMware Build Numbers

Easiest way to view ESX/ESXi log files

What is the fastest way to retrieve log files from an ESXi host? In my opinion, the best way is to configure remote logging via syslog server but this requires host reboot to apply configuration changes (KB1016621). The alternative method is to forward log files to different datastore. 
If  you don't have prepared syslog server for remote logging you can use vsphere client and generate system log bundles for particular host. But this takes some time. 
The last method is I think the fastest one because it will allow you to access log files  directly with your web browser. You can use web interface of the ESXi host,  enter the following URL:

https://ESXi_HOST_ADDR/host

The output should looks like shown at this picture:
You can download ESXi log files  messages, hostd.log and vpxa.log  now.

Saturday, April 9, 2011

Upgrade ESX3.5 to ESX4 with vSphere Host Update Utility

In this post, I would like to introduce vSphere Host Update tool. With this tool you’re able to update an ESX host without VMware Update Manager, just like the VMware Infrastructure Update utility. This utility tool is an optional tool & bundled inside vSphere Client installer, this means that you can install it while you are installing vSphere Client. In this post I will guide you through the upgrade process of an ESX 3.5 host which runs on HP Proliant DL380 G4.
Start the vSphere Host Update Utility here:
vSphere Host Update Utility 4.0
At the same time, fire-up your Virtual Infrastructure Client & login to the existing ESX3.5 server with Update 3, as shown as below. As a reminder, any upgrade on ESX host process only can be proceed while it is in maintenance mode.
existing ESX 3.5 server update 3
Now back to the new utility. First what we need to do is adding ESX host by clicking Add Host at the right top of the utility window & enter the ESX server IP address.
Add ESX host
After added the ESX host, so now we’re ready to upgrade. Select the host and press the upgrade button.
added ESX hosts
The ESX 4.0 Upgrade Wizard starts. You’ll have to add the upgrade iso file which you can download from VMware.com which available on 21st May 2009 onwards.
ESX ugrade wizard
Enter the credentials for your host. If you haven’t set the ESX host enter maintenance mode, you’ll see an error as below:
ESX credentials

So beware, any upgrade on ESX host process only can be proceed while it is in maintenance mode.
Then it will run compatibility check on ESX host.
compatibility check
Next you’ll be prompted to assign the Console OS disk size & disk location. At this practice, i assign 10GB.
Concole OS setting
At the next window, just tick the first option in order to make sure the existing ESX server will not be corrupted in case of any upgrade failure occurs.
post upgrade
Now, you are ready to complete the wizard & starts the upgrade process.
wizard complete
Firstly, it will copy the entire ISO image to the ESX server for a faster upgrade process & avoid any network interruption upon post-upgrade is running on.
copy ISO image
After finishing copied, it starts to install new packages for ESX 4.0.
Installing packages
While this process is running, your VI Client which connected to the ESX host will be disconnected as-well.
This is due to the new updates on Apache Tomcat & some web services.
Finally, you will successfully upgraded to the ESX 4 if everything goes smooth like my practice.
upgrade suceeded
And now, you can use vSphere Client to login to new ESX 4.0 to see the new interface of ESX 4.0.

'VMware Server cannot find the virtual disk' on VMware Server

Summary
When starting the VM on Blade 5, the following error appears:
    VMware Server cannot find the virtual disk "//disk3.vmdk". Please verify the path is valid and try again. Cannot open the disk '//disk3.vmdk' or one of the snapshot disks it depends on. Reason: The system cannot find the file specified.
You may find that the your file equivalent of "disk3.vmdk" may not be found. However, other files may be found:
    -r--r--r-- 1 root root 11 Dec 21 16:38 disk3.vmdk.RESLCK.WRITELOCK
    -rw------- 1 oracle dba 4096 Sep 25 17:52 disk3.vmdk.RESLCK
    -rw------- 1 oracle dba 437 Dec 12 13:41 disk4.vmdk
    -rw------- 1 oracle dba 437 Dec 12 13:41 disk5.vmdk
    -rw------- 1 oracle dba 437 Dec 12 13:41 disk6.vmdk
    -rw------- 1 oracle dba 434 Dec 12 13:34 disk7.vmdk
    -rw------- 1 oracle dba 434 Dec 12 13:37 disk8.vmdk
Deleting the disk3.vmdk.RESLCK.WRITELOCK file did not make a difference.

Details
1. Manually create the //disk3.vmdk file (copy any of the other ones, e.g. disk5.vmdk), and change the following two values:
CID=0187ef8f                   <-- this should be a random number
RW 20971520 FLAT "/dev/sdh" 0  <-- change this to /dev/sdh or equivalent to your environment

Explanation why I used "0187ef8f":
Per http://sanbarrow.com/vmdk/vmdk-basic-CID-chain-repair.html, CID was a number randomly assigned by VMware Server. I figured, why not use a random CID (I just used the one in the website), after confirming that it's not in any of the .vmdk files.

Explanation why I used /dev/sdh:
All the other .vmdk files were already pointing to various files under /dev:
    disk4.vmdk: RW 20971520 FLAT "/dev/sdi" 0 disk5.vmdk: RW 20971520 FLAT "/dev/sdj" 0 disk6.vmdk: RW 20971520 FLAT "/dev/sdk" 0 disk7.vmdk: RW 2097152 FLAT "/dev/sdl" 0 disk8.vmdk: RW 2097152 FLAT "/dev/sdm" 0
So that leaves the only available ones:
    /dev/sdg /dev/sdh
Since lun33.vmdk was the first file, I chose to use /dev/sdh which was the one immediately preceding /dev/sdi and used by lun34.vmdk. This was a risk, but what choice did I have?

2. The VM server started up!!!

Wednesday, April 6, 2011

Application Virtualization (App-V) 4.6 – Video Demonstrations and Tutorials

Learn how to create, configure, publish, and maintain virtual applications with Microsoft Application Virtualization with these eight new short videos from the Springboard Series.

 

Create a Virtual Application Using the App-V Sequencer

The Application Virtualization (App-V) Sequencer is a powerful, easy-to-use tool that enables IT professionals to create a new virtual application. This video will walk you through the different files that make up a virtual application package and teach you how to:
  • Run the App-V 4.6 Sequencer to sequence an application.
  • Create file type associations and shortcuts.
  • Configure a custom application package.

 

Launch a Virtual Application and Review Client Configuration

The Application Virtualization (App-V) Client provides the IT administrator with many flexible configuration options depending on their enterprise business requirements. This video will outline the user experience when launching an application and demonstrate:
  • How to apply configuration at package time, such as Send To and File Type Associations (FTAs).
  • How to remove the App-V notification when an application launches, and other client configurations.
  • How App-V provides a seamless user experience while leveraging the power of virtualization to avoid application conflicts and installation.

 

Publish a Virtual Application Using Full Infrastructure Mode

The Application Virtualization (App-V) Management Console enables you to publish virtual applications to your end users as well as create license metering rules and run reports about your applications. In this screencast, you’ll learn how to:
  • Import a virtual application for publishing.
  • Create File Type Associations (FTAs) if you chose not to do them at sequence time.
  • Assign applications to the appropriate users via Active Directory security distribution groups.

 

Update a Virtual Application Using App-V

All Application Virtualization (App-V) application updates occur when the user launches the application. Updating virtual applications using App-V is a simple process that does not impact user productivity because it does not require the user to install an application, or reboot. Familiarize yourself with the upgrade experience from a user perspective then learn how to update a virtual application using App-V.

 

Deprovision a Virtual Application

One of the great capabilities provided by Application Virtualization (App-V) is its ability to seamlessly deprovision the application without impacting user productivity, requiring user or application downtime, or requiring the need to uninstall or reboot. This screencast will show you how to quickly and easily deprovision a virtual application using App-V.

 

Run Microsoft Office in an App-V Virtualized Environment

 Microsoft Application Virtualization (App-V) provides the ability to deliver virtual applications to users on demand out of the box. With App-V, you can run multiple versions of applications on the same computers where small groups of users will not be adversely impacted by fast deployment and speedy migration, or incompatibilities in file formats between versions of the same applications. In this video, we’ll demonstrate how two different versions of Microsoft Office Word can run side-by-side, and how data can be shared between the different versions.

 

Use App-V Metering to Manage Application Licenses

Microsoft Application Virtualization (App-V) provides the ability to deliver, meter, and manage virtual applications on demand out of the box without requiring any additional software or tools. This screencast will demonstrate:
  • How to create, apply, and report on a metering rule.
  • The user experience when a rule is enforced.
  • The importance of metering in assisting IT to controlling access and in purchasing the appropriate number of application licenses.

 

Use Dynamic Suiting to Create a Plug-in Dependency for Virtual Applications

Dynamic Suite Composition (DSC) provides the ability to link applications together to create a small footprint for each application by sharing common, non-conflicting dependencies such as add-ins and middleware components. DSC also helps simplify permissions so that, once permissions are granted to the user, the user will automatically receive the plug-in the next time the application is launched without waiting for installation or having to perform an additional activity. This video will walk you through the simple process of using the DSC tool, and show you how to create a plug-in dependency in Microsoft Office Word using DSC.
Access additional resources including a Getting Started Guide, planning and design guidance, and security best practices on the MDOP page. Also read – 64-bit version of App-V 4.6 Download and MDOP 2010 Launches!

Advanced Group Policy Management (AGPM)

Microsoft Advanced Group Policy Management is a component of the Microsoft Desktop Optimization Pack for Software Assurance (MDOP SA).
The Advanced Group Policy Management (AGPM) increases the capabilities of the Group Policy Management Console (GPMC), providing:
  • Standard roles for delegating permissions to manage Group Policy objects (GPOs) to multiple Group Policy administrators.
  • An archive to enable Group Policy administrators to create and modify GPOs offline before deploying them to a production environment.
  • The ability to roll back to any previous version of a GPO.
  • Check-in/check-out capability for GPOs to ensure that Group Policy administrators do not overwrite each other's work.
If you want to more information about what it brings, have a look at the Advanced Group Policy Management datasheet.
Some features include:
• Offline editing of GPOs
• Difference reporting and audit logging
• Recovery of a deleted GPO (Recycle Bin)
• Repair of live GPOs
• Creation of GPO template libraries
• Subscription to policy change e-mail notifications
• Version tracking, history capture, and quick rollback of deployed changes
• Role-based administration (Editor, Reviewer, Approver)
• Change request approval
AGPM is built out of a client and server component, which need to be installed.
AGPM Server will host the "AGPM Service" and manages the GPO archive.  All AGPM operations are managed through this Windows service and are executed with the service's credentials.  AGPM stores all versions of each controlled Group Policy object (GPO) - which is a GPO for which AGPM provides change control - in a central archive, so that Group Policy administrators can view and modify GPOs offline without immediately impacting the deployed version of each GPO.
Each Group Policy administrator - anyone who creates, edits, deploys, reviews or deletes GPOs - must have the AGPM Client installed on computers that they use to manage GPOs.

Installation Requirements

AGPM Client requires Windows Vista (32-bit version) or Microsoft Windows Server 2003 (32-bit version) as well as the Group Policy Management Console (GPMC).  AGPM Client can be installed on the same computer running the AGPM Server.
AGPM Server requires Windows Vista (32-bit version) or Microsoft Windows Server 2003 (32-bit version) as well as the Group Policy Management Console (GPMC).  Additionally, you must be a member of the Domain Admins group to install AGPM Server.  The AGPM Server component can be installed on a member server or domain controller.

1. AGPM Server Installation Process


  • In the Welcome dialog box, click Next.


  • In the Application Path dialog box, select a location in which to install AGPM Server.  The computer on which AGPM Server is installed will host the AGPM Service and manage the archive.  Click Next.

  • In the Archive Path dialog box, select a location for the archive relative to the AGPM Server. The archive path can point to a folder on the AGPM Server or elsewhere, but you should select a location with sufficient space to store all GPOs and history data managed by this AGPM Server. Click Next.


  • In the AGPM Service Account dialog box, select a service account under which the AGPM Service will run and then click Next.
    AGPM Service Account

  • In the Archive Owner dialog box, select an account or group to which to initially assign the AGPM Administrator (Full Control) role. This AGPM Administrator can assign AGPM roles and permissions to other Group Policy administrators (including the role of AGPM Administrator). Click Next.

    Click Install, and then click Finish to exit the Setup Wizard.

    2. AGPM Client Installation Process


  • In the Welcome dialog box, click Next.


  • In the Application Path dialog box, select a location in which to install AGPM Client. Click Next.


  • In the AGPM Server dialog box, type the fully-qualified computer name and the port for the AGPM Server to which to connect. The default port for the AGPM Service is 4600. Click Next.

    Click Install, and then click Finish to exit the Setup Wizard.

    GPMC User Interface changes
    Advanced Group Policy Management (AGPM) adds a Change Control node to each domain displayed in the Group Policy Management Console (GPMC).  In an environment where multiple domains are managed with the GPMC, each domain is listed under the Domains node in the console tree. 
    Within the details pane there are 3 primary tabs, providing access to both GPO-level settings and domain-level settings for AGPM.
    1. Contents Tab: GPO settings and commands and GPO-level delegation
    2. Domain Delegation Tab: AGPM e-mail notification settings and domain-level delegation
    3. AGPM Server Tab: Domain-level archive connection settings

    AGPM adds a History tab to all Group Policy objects (GPOs) and Group Policy links displayed in the GPMC.  The features of the History tab in the details pane of a GPO are the same as those of the History window displayed through the Change Control tab (by double-clicking a "controlled/uncontrolled GPO").

    In the Microsoft Windows Server 2003 operating system (only!), AGPM adds an Extensions tab to all GPOs and Group Policy links displayed in the GPMC.  This tab lists all extensions that contain settings in the GPO (or all registered extensions if "Show all registered extensions" is checked) and identifies them as part of the user or computer context.


    AGPM Administrative Template
    AGPM is shipped with an administrative template (AGPM.ADM located in the %windir%\inf) containing settings for Advanced Group Policy Management (AGPM) to enable you to centrally configure logging and tracing options for AGPM clients and servers to which a Group Policy object (GPO) with these settings is applied.  Similarly, these settings enable you to centrally configure archive locations and the visibility of the Change Control node and History tab for Group Policy administrators to whom a GPO with these settings is applied.

    Role based administration 

    In an environment where multiple people build/edit Group Policy objects (GPOs), you can delegate specific tasks to specific people for specific GPOs based on a role model (Reviewer, Editor, Approver, Administrator).
    AGPM Administrators can delegate permissions to "Editors" who make changes to GPOs and to "Approvers" who deploy GPOs to the production environment.  AGPM Administrators can configure permissions to meet the needs of your organization, since the "AGPM Administrator" role includes the permissions for all other roles and thus can perform the tasks normally associated with any other role.
    • Approvers can perform "Approver Tasks", such as creating, deploying, or deleting GPOs
    • Editors can perform "Editor Tasks", such as editing, renaming, labeling, or importing GPOs, creating templates, or setting a default template
    • Reviewers can perform "Reviewer Tasks", such as reviewing settings and comparing GPOs
     
    NOTE:
    To delegate (read) access to Group Policy administrators who use AGPM, you must grant them "List Contents" as well as "Read Settings" permissions (Reviewers role).  This enables them to view GPOs on the Contents tab of AGPM.  Set the permission to apply to This object and nested objects.

    For more information: Advanced Group Policy Management datasheet
    Also watch the AGPM video presented by Kevin Sullivan, Senior/Lead Program Manager in Group Policy Product Team (23 min)
    Or listen to the AGPM talk on Technet Radio on AGPM (15 min)

    Related blog post: Windows Server 2008 & Group Policy Management Console (GPMC)

  • Monday, April 4, 2011

    Linux VM No Longer Boots After Upgrade To ESXi 4.1

    One Linux VM was recently upgraded to ESXi 4.1 and found that all of the Windows servers work fine but the Linux server will not boot. 

    The error message when the linux server tries to boot suggests trying to boot with the NOAPIC option 


    Solution:
    From Redhat AS4 update 7, 'noapic'  is  disabled. Kernel versions before have to hardcord 'noapic' under grub.conf


    VMware: “Failed to read the upgrade package metadata.xml” upgrading to ESXi 4.1

    I was upgrading my ESXi 4.0 Update 2 host to ESXi 4.1 with “VMware vSphere Host Update Utility”, I downloaded the “ESXi 4.1 (upgrade ZIP from ESXi 4.0)” file and selected this package to upgrade the host. After validating the upgrade package I received this error:
    Failed to read the upgrade package metadata: Could not find file metadata.xml
    image

    I’ve checked the MD5 checksum.. it was correct.. I downloaded again the upgrade package from the VMware site.. still this warning..
    Solution:
    ESXi doesn’t support SSH shell or, but there is a “hack” to connect the console or connect over SSH for the command line interface. Check: http://blog.vmpros.nl/2008/12/25/vmwareesxi-35-does-ship-with-the-ability-to-run-ssh/
    With my VI Client I connected the datastore and uploaded the upgrade package in a new created folder called: “upgrade”

    image

    - Put the ESXi host in maintenance mode ^ 

    image

    - Connect the console and browse the /vmfs/volumes/[datastore01]/upgrade/ path^

    image

    – Give the command: “esxupdate update –m metadata.zip” and the upgrade from ESXi 4.0 Update 2 to ESXi 4.1 will be installed.. reboot your host ^


    image

    My ESXi4.0 U2 is succesfully upgraded to ESXi 4.1 :D