As you know, we’re in the trenches everyday with customers designing and implementing virtualization solutions (and answering lots of questions!). Therefore, we thought it would be helpful to add to the exiting opinion and analysis with our view. Especially given the fact that this release is much more than simple bug fixes and updates.

So, over the next several weeks, I’ll be writing a “What’s New in vSphere 5.1 & Why You Want It”? series, right here, on the eGroup blog. Be sure to come back often – in the meantime, if you have any questions on vSphere 5.1, share in the comments.

Here are some vSphere 5.1 features to look forward to:

• vMotion: I know, I know, “But vMotion launched in 2003!” And you’re right, it did. But this is the second coming of vMotion – and it’s as cool as the first one was. vMotion has lost its shared storage requirement. You no longer have to present the same storage over NFS, iSCSI, FC, or FCoE to all the hosts in a cluster in order to enable vMotion. If you’re planning for a simultaneous compute and storage upgrade, you no longer need to deploy your new hardware in stages – just configure your new hosts and storage together and bring your VMs across on your existing vMotion network.
• vSphere Distributed Switch: The fastest and easiest way to manage your virtual networking got several improvements in vSphere 5.1. You can now monitor the health of your vSphere Distributed Switch in three main areas: VLANs, MTU, and Teaming and Failover. If your physical uplink ports don’t have identical VLANs trunked, if your MTU is mismatched between your vDS and your physical switches, or if your physical link aggregation doesn’t match your virtual configuration, the vSphere 5.1 vDS can now alert you of these problems. You can now also backup and restore a vDS config or even backup and restore to a duplicate vDS to clone an existing configuration. Most importantly, if any change to the vDS configuration ever isolates a host from vCenter, that host will automatically rollback to the previous configuration when it detects the isolation. The vDS management ports can also be managed directly from the ESXi DCUI (the physical host console).
• Little Things Matter!: VMware Tools upgrades no longer require VM reboots! The vSphere 5.1 VMware Tools upgrade will be the last time you have to reboot your VMs just to upgrade the Tools. Uptime, here we come!

Check back for part two coming soon!

Oh, and if you are attending the Carolina Technology Conference on Tuesday, October 9, eGroup is hosting two labs, “Hands on with vSpehere 5.1.” Come see your lab host, John Flisher.

The post What’s New in vSphere 5.1 & Why You Want It: Part 1 appeared first on eGroup.

• Guideline Title: Verify contents of exposed configuration files
  • Title: verify-config-files
  • Discussion: Certain configuration files exist on ESXi hosts that govern host behavior and operations. These files should be logged and monitored for both authorized and unauthorized configuration changes. These files can be retrieved over HTTPS via http://<hostname>/host if the Managed Object Browser (MOB) is enabled. However, a separate VMware hardening recommendation we’ve previously covered advises that the MOB be disabled. If your organization chooses not to accept the risk of leaving the MOB enabled, these configuration files can also be retrieved via vCLI or PowerCLI.
  • Official VMware documentation
• Guideline Title: Keep ESXi system properly patched
  • Title: apply-patches
  • Discussion: ESXi is designed from the ground up to be a powerful but secure hypervisor with minimal attack surface area. A complete install disc is less than 300MB. ESXi needs patches much less frequently than ESX used to, but it does still need them. VMware Update Manager is a free tool included with vCenter to help automate the patching of ESXi hosts during production hours with no VM downtime. To stay on top of the latest VMware Security Advisories by email you can also subscribe here.
  • Official VMware documentation

Note: I’m collapsing the next three hardening guide checks into a single entry since they are almost identical. I will point out in the discussion section where they differ.

• Guideline Title: Verify Image Profile and VIB Acceptance Levels
  • Title(s): (1) verify-acceptance-level-certified, (2) verify-acceptance-level-accepted, (3) verify-acceptance-level-supported
  • Discussion: vSphere Installation Bundles (VIBs) are files that can be used to extend ESXi functionality. They might perform functions such as enabling hardware status monitoring, adding new hardware drivers, or enabling third-party security virtual appliances. These VIBs can have one of four available acceptance levels: VMwareCertified, VMwareAccepted, PartnerSupported, and CommunitySupported. As their names imply, these four levels relate to the entity that tested and possibly certified the VIBs for use. When you configure the VIB Acceptance Level, you are instructing your ESXi hosts to only install VIBs that meet or exceed the specified level of support and testing.
    • -VMwareCertified – these VIBs are created, tested, and signed by VMware. This is the recommended setting for environments hosting extremely sensitive data, including military environments authorized to handle classified data.
    • -VMwareAccepted – These VIBs are created by a VMware Partner but are tested and signed by VMware. This is the recommended setting for environments hosting sensitive data or those subject to stricter compliance requirements.
    • -PartnerSupported – These VIBs are created, tested, and signed by a certified VMware Partner. This is the recommended setting for all vSphere environments.
    • -CommunitySupported – These VIBs are neither supported nor digitally signed. CommunitySupported VIBs should not be installed on production vSphere environments.
  • Official VMware documentation

The post VSPHERE 5.0 HARDENING GUIDE DISCUSSION – PART 5 appeared first on eGroup.

• Guideline Title: Disable SSH
  • Title: disable-ssh
  • Discussion: We all know and love SSH. It’s an encrypted way to access a command line on a remote system. But the truth is that a stopped service is infinitely harder to exploit than a running service. SSH should only be enabled as necessary for troubleshooting and then should be stopped again.
  • Official VMware documentation
• Guideline Title: Enable lockdown mode to restrict remote access
  • Title: enable-lockdown-mode
  • Discussion: Lockdown mode is often incorrectly thought to be an extra layer of security for your ESXi hosts. What it really does is restrict who can login to the host and from where. Under normal vSphere operations, an ESXi host is managed by vCenter. However any user with the root password or a local account can connect directly to the host with the vSphere client. Since the root account it often known by more than one person, configuration changes made by “root” cannot be traced back to a specific individual. Lockdown modes restricts logins by all users from the vSphere client and from all users except root on the console. This forces all users to login to vCenter using Active Directory credentials in order to modify host settings and creates a record of who modified host settings and when. Note: root can still login to the local console when lockdown mode is enabled. This constitutes a change in behavior from previous versions of ESXi.
  • Official VMware documentation
• Guideline Title: Do not provide root/administrator level access to CIM-based hardware monitoring tools or other 3rd party applications
  • Title: limit-cim-access
  • Discussion: CIM modules are commonly used to monitor ESXi host hardware and are provided by vendors such as Cisco, Dell, and HP. These modules have the capability of creating additional users on ESXi hosts and these users should only be given necessary permissions for monitoring. Avoid granting root permissions if it can be avoided.
  • Official VMware documentation
• Guideline Title: Remove keys from SSH authorized_keys file
  • Title: remove-authorized-keys
  • Discussion: We stated earlier that SSH is a great way to access a command line for a remote system securely and easily. But SSH access can get even easier – by using SSL key pairs. When a user generates an SSL key pair, they can choose to paste the contents of their public certificate into the /etc/ssh/keys-root/authorized_keys directory. When they open an SSH session, the ESXi host will issue a challenge encrypted with the stored public key. If the user is on a computer that stores the matching private key, the challenge can be decrypted and the user is allowed to logon without entering a password. Monitor the authorized_keys file regularly to ensure that no one has added their public key as a trusted SSH key.
  • Official VMware documentation
• Guideline Title: Set a timeout for the ESXi Shell to automatically disable idle sessions after a predetermined period
  • Title: set-shell-timeout
  • Discussion: SSH (even when normally disabled and used sparingly only for troubleshooting) should be configured to end idle sessions. This is the ESXi equivalent of a password-protected screensaver policy for sysadmin workstations.
  • Official VMware documentation

The post VSPHERE 5.0 HARDENING GUIDE DISCUSSION – PART 4 appeared first on eGroup.

• Guideline Title: Enable SSL for NFC
  • Title: enable-nfc-ssl
  • Discussion: NFC (Network File Copy) is used to copy or migrate VMs between ESXi hosts. The vulnerability being addressed here is network traffic sniffing. If an attacker sniffed NFC traffic as it was being used to ship an entire VM, they would get an effective duplicate of your entire virtual server. Normally turning SSL on here would be an easy decision to recommend, but in this case, VMware’s guidance on this issue is that NFC over SSL between ESXi hosts “has … not been extensively tested and so may cause HA and other operations to fail in certain circumstances.” Ouch. We’ll keep our eye on this one and hope that NFC over SSL gets more testing in the future. In the meantime, make sure your vSphere management networks and VLANs are sufficiently isolated as a partial mitigation.
  • Official VMware documentation
• Guideline Title:  Do not use default self-signed certificates for ESXi communication
  • Title: esxi-no-self-signed-certs
  • Discussion: This hardening guidance is written towards vSphere, but it’s always good guidance for any system that uses encryption, even plain ol’ Windows Remote Desktop! Wikipedia has a detailed explanation of man-in-the-middle attacks, but here’s the gist: whenever you choose to connect to a server with an unverified SSL certificate, you have no certainty that your encrypted SSL tunnel reaches all the way to the server you’re talking to. It’s possible that your traffic is being intercepted, decrypted, stored, re-encrypted, and sent to its destination – all without you or the server you’re connecting to being aware your traffic was intercepted. Self-signed SSL certs are generic and hard to distinguish from each other. They also lose the benefit of having a Certificate Authority confirm the validity of the cert. The solution is always replace default/vendor certificates on all network endpoints with certs issued by a commercial or organizational Certificate Authority.
  • VMware Official documentation
• Guideline Title: Prevent unintended use of dvfilter network APIs
  • Title: verify-dvfilter-bind
  • Discussion: The dvfilter network APIs are part of the larger VMsafe API and they allow VMware partners to develop virtual security appliances to control the behavior of guest virtual machines. These virtual appliances have the benefit of simplifying guest VM configuration while increasing the overall security of your environment. Some great examples of this include Trend Micro Deep Security, the Cisco Virtual Security Gateway, and the Juniper Virtual Gateway. These appliances allow you to manage firewalls around your VMs as easily as dragging and dropping VMs in vCenter, enabling secure VM isolation (e.g. “DEV servers can’t talk to PROD servers”) but without sacrificing any ease of management (one of the reasons we virtualized everything in the first place, right?) These virtual security appliances using the dvfilter APIs receive privileged access to other guest VM network traffic. If you’re not using any security appliances that leverage these APIs, you’ll want to confirm they’re not in use to prevent a malicious VM from receiving the data instead.
  • Official VMware documentation is still TBD
• Guideline Title: Disable DCUI to prevent local administrative control
  • Title: disable-dcui
  • Discussion: NOTE: This is only recommended by VMware for the most secure environments. The DCUI is the name of the service that runs the gray and yellow console screen we all see when we first install ESXi and then promptly forget exists. This service can be stopped (and configured to not auto-start) which prevents any operations from occurring at the console or over a KVM. Be very careful and know the impact of this change. If you misconfigure a vSwitch and knock your host management kernel port offline, there’s no parachute to reset the host vSwitch and you might be reaching for an ESXi install disk.
  • Official VMware documentation is still TBD
• Guideline Title: Disable ESXi Shell unless needed for diagnostics or troubleshooting
  • Title: disable-esxi-shell
  • Discussion: This is known by some as the ESXi command line, formerly known as Tech Support Mode. From an ESXi console, you can press Alt+F1 and login as root to access a BusyBox environment that looks and acts a bit like Linux but has full control over host operations. The ESXi Shell should be started as necessary through the vSphere console for troubleshooting purposes and remain stopped the rest of the time.
  • Official VMware documentation

The post VSPHERE 5.0 HARDENING GUIDE DISCUSSION – PART 3 appeared first on eGroup.

• Guideline Title: Communication Configure the ESXi host firewall to restrict access to services running on the host
  • Title: config-firewall-access
  • Discussion: The process of hardening a production server involves stopping unnecessary services and protecting services that need to remain running, and ESXi is no different. Unnecessary services should be disabled. Necessary services can be protected by defining allowed IPs that are allowed to connect. These IPs can be set under “Configuration -> Security Profile -> Firewall -> Properties”. Select a service then click “Firewall”, choose “Only allow connections from the following networks” and specify the IPs or ranges that will be allowed to connect.
    
  • Official VMware documentation
• Guideline Title: Configure NTP time synchronization
  • Title: config-ntp
  • Discussion: NTP serves two purposes. First,  in the event of a security breach, having your ESXi system logs synchronized will lend itself to an effective incident postmortem, which can, in turn, help increase the security of your environment and further remediate vulnerabilities. Second,  NTP will be used by any VMs that utilize the VMware Tools time synchronization. When the host has accurate time, the VMs using it as a time source will also. I prefer to pick a single device inside the firewall (possibly the firewall itself) to serve as my internal NTP source. Then I have all my other hosts sync against that device. This means that if the internet connection goes down, only one system notices and the rest of the systems all stay in sync with each other, though not necessarily with the rest of the world. So set an NTP server choose ”Configuration -> Time Configuration -> Options -> start the NTP service and select “Start and stop with host”". Click ‘Add’ and specify your site’s NTP servers.
  • Official VMware documentation
• Guideline Title: Ensure proper SNMP configuration
  • Title: config-snmp
  • Discussion: SNMP is a protocol for monitoring network resources (hosts, servers, switches, etc). If your environment is not using SNMP, it should be disabled to avoid disclosing ESXi host status information to malicious observers. (Of course, if you’re following along, you’ve already locked down which IPs and ranges can reach the SNMP agent!) The ESXi SNMP agent is disabled by default. To confirm this, run “vicfg-snmp <conn_options> –show”, or to disable it in environments where it is not used, run “vicfg-snmp <conn_options> –disable”. If SNMP is being used, make sure the parameters are properly configured using either vCLI or PowerCLI, or using an API client.
  • Official VMware documentation
• Guideline Title: Disable Managed Object Browser (MOB)
  • Title: disable-mob
  • Discussion: I can’t put it any better than the VMware-provided description for this vulnerability already has. I’ll quote it below directly from the Hardening Guidelines.
    • “The managed object browser (MOB) provides a way to explore the object model used by the VMkernel to manage the host; it enables configurations to be changed as well. This interface is meant to be used primarily for debugging the vSphere SDK but because there are no access controls it could also be used as a method obtain information about a host being targeted for unauthorized access. To determine if the MOB is enabled run the following command on the ESXi shell: “vim-cmd proxysvc/service_list”. To disable the MOB run the following command: “vim-cmd proxysvc/remove_service “/mob” “httpsWithRedirect”". Note: You cannot disable MOB while in lockdown mode. The MOB will no longer be available for diagnostics. Some 3rd party tools use this interface to gather information. Testing should be done after disabling the MOB to verify 3rd party applications are still functioning as expected. To re-enable the MOB: ~ # vim-cmd proxysvc/add_np_service “/mob” httpsWithRedirect”
  • Official VMware documentation
• Guideline Title: When adding ESXi hosts to Active Directory use the vSphere Authentication Proxy to protect passwords
  • Title: enable-auth-proxy
  • Discussion: In environments that use both ESXi Autodeploy and Active Directory to manage hosts, the password used to join Active Directory is sent in cleartext to each host as it boots up, which puts that password at great risk of interception. Instead, VMware provides a vSphere Authentication Proxy to help keep this communication secure. Here are the official deployment instructions.
  • Official VMware documentation

We’ll pick this back up tomorrow and knock out another 5 ESXi hardening checks!

The post VSPHERE 5.0 HARDENING GUIDE DISCUSSION – PART 2 appeared first on eGroup.

Since the hypervisor is the heart of your datacenter, let’s start with the ESXi guidelines:

• Guideline Title: Use Active Directory for local user authentication
  • Title: enable-ad-auth
  • Discussion: The credentials to your ESXi hosts are among the most sensitive in your entire datacenter. The root password should only be given to personnel that have an explicit need for it. Other users that need to login to hosts outside of vCenter can have permissions granted to their Active Directory account. David Davis has a great video demonstrating the process. By default, an AD group names “ESX Admins” is checked for and all members will have full rights to all hosts.
  • Official VMware documentation
• Guideline Title: Establish a password policy for password complexity
  • Title: set-password-complexity
  • Discussion: This setting is used to enforce strong passwords for local accounts. You know, the local accounts you’re not using since all your hosts are joined to AD, right? But seriously, this is a great setting to use to force users to pick strong passwords, even if your hosts have no local users. Configuration drift happens, so let’s plan ahead and make sure these users will have strong passwords. Using vi, you’ll edit the file /etc/pam.d/passwd and modify the third line. The default value is “password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6″. The retry value controls how many attempts users get to pick a strong password. The last 5 numbers control your desired complexity settings, in the following order and referencing four character classes (uppercase letters, lowercase letters, numbers, and symbols/special characters):
    • The first digit is the minimum length for passwords containing characters from 1 of the classes (least complex, e.g. using “password” as your password). You’ll want this to be a very large number.
    • The second digit is the minimum length for password containing characters from 2 of the classes. You’ll also want this to be a very large number.
    • The third digit is the minimum length of SSL certificate passphrases
    • The fourth digit is the minimum length for password containing characters from 3 of the classes. Now were getting into reasonable passwords, so allow whatever reasonable length your organization permits.
    • The fifth digit is the minimum length for password containing characters from 4 of the classes (most complex, e.g. using “p4$wOrd” as your password”). Same as the previous line.
  • Official VMware documentation
• Guideline Title: Verify Active Directory “ESX Admin” group membership.
  • Title: verify-admin-group
  • Discussion: now that our hosts are joined to AD (first bullet point above), we want to audit the membership of “ESX Admins” since those users will automatically have root-level permissions to our hosts. This is a manual check, but you’ll also want to automate it so that it can run regularly. You can write a scheduled Powershell script to read the group membership and email you the contents on a schedule, or products like ADAudit Plus from ManageEngine are perfect for this task and can email you only when group membership changes.
  • Official VMware documentation
• Guideline Title: Ensure that vpxuser auto-password change meets policy.
  • Title: vpxuser-password-age
  • Discussion: ESXi contains a built-in user account called vpxuser. This account has Administrator-level permissions to the local host and is used by vCenter to execute tasks. vCenter sets this password and changes it automatically every 30 days. If your organization requires more frequent password changes, you can change this from the vSphere client by selecting “Administration -> vCenter Server Settings -> Advanced Settings” and changing VirtualCenter.VimPasswordExpirationInDays to your desired interval.
  • Official VMware documentation
•  Guideline Title: Ensure that vpxuser password meets length policy.
  • Title:vpxuser-password-length
  • Discussion: Similar to the guideline above, this check confirms that the password length for the vpxuser password is long enough to comply with your organization’s security policy. By default it is set to 32 characters. To increase this password length, modify the “vpxd.hostPasswordLength” value in the vpxd.cfg file. On Windows this file is located at C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg  or on the vCenter Server Appliance you’ll find it at /etc/vmware-vpx/vpxd.cfg.
  • Official VMware documentation

That’s it for today! I’ll see you all back here tomorrow to continue our discussion on the vSphere 5.0 Hardening Guide.

The post VSPHERE 5.0 HARDENING GUIDE DISCUSSION – PART 1 appeared first on eGroup.

I double checked the vSphere client to verify that the host detected that VMware tools was installed and receiving guest heartbeats – all appeared to be well. The VM Device Manager listed a “PS/2 Compatible Mouse” installed as the mouse rather than a “VMware Pointing Device”. The fix was to force a driver update and use the VMware mouse driver located at C:\Program Files\Common Files\VMware\Drivers\mouse. The VMware Communities led me to a permanent fix for this problem as well: before running sysprep and converting your VM to a template, load the Registry Editor and browse to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Sysprep\Settings\sppnp where you can set PersistAllDeviceInstalls to 1. This registry key tells the guest OS not to remove any drivers for devices that are currently present. Since the virtual hardware for every VM deployed from the template will be identical, it will be safe to leave all drivers in place.

For complex sysprep deployments utilizing an XML answer file, the following code can be used to achieve the same effect:

<settings pass="generalize">
 <component name="Microsoft-Windows-PnpSysprep" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
 </component>
 </settings>

Special thanks to crkusch, arbsysts, and the VMware Communities for sharing their knowledge that makes this fix possible.

The post 2008R2 VM TEMPLATES AND MOUSE DRIVERS appeared first on eGroup.

Here’s the whole script. Lines are marked with a number and parenthesis to avoid confusion with text wrapping.

1) Add-PSSnapin VMware.View.Broker
2) Connect-VIServer <your View Connection Server hostname>
3) $a = get-date ((get-date).AddMinutes(2)) -format "yyyy-MM-%d HH:mm"
4) Get-Pool -pool_id <your pool ID> | Get-DesktopVM | Send-LinkedCloneRefresh -schedule $a

Let’s step through each line of the script and dig into what it does. Since this is a Powershell script, the first line needs to import the VMware View snapins for Powershell.

Line 2 logs the script in to your View Connection Server. To avoid saving a password in cleartext in the script, we’ll have Windows store the credentials for the account this script will run as (more on that later).

The third line assigns the $a variable a time reference that is two minutes in the future. The specific formatting modifies the native Get-Date result into the time format that the next line is expecting. yyyy is a 4 digit year, MM is the numeric month with leading zeroes where appropriate, %d is the numeric day of the month without leading zeroes, HH is the hours in a 24-hour clock format, mm is the minutes past the hour. Be careful – almost all these tokens are case-sensitive (e.g. MM vs. mm).

The last line actually schedules the View Pool refresh for two minutes in the future using the variable we just built and formatted. You can find your View Pool ID listed in your View Connection Server.

Save all this text in text file with a .ps1 extension to let the system know it’s a Powershell script. Add a new task to Task Scheduler on your View Connection Server. You’ll want this task to run with highest privileges and run as a user that has administrative rights to your View environment (this is why you don’t have to specify credentials in the script). For the script action, the program to run is

C:\Windows\system32\WindowsPowershell\v1.0\powershell.exe

and the optional argument is the path to your .ps1 script.

The post REFRESH YOUR VMWARE VIEW POOLS WITH POWERCLI appeared first on eGroup.

• ESX 3.5-4.1 and ESXi 3.5-4.1 should install available patches to address a ROM Overwrite vulnerability that allows privilege escalation in Windows 2000 through 2003 R2 guests (CVE-2012-1515).
• ESX 4.0 should install available patches to update the service console to kernel-400.2.6.18-238.4.11.591731 and fix multiple inherited vulnerabilities (
  CVE-2011-2482, CVE-2011-3191, and CVE-2011-4348). The patch for ESXi 4.1 is still pending.
• ESX 4.0 should install available updates to patch Kerberos vulnerabilities (CVE-2011-4862).

As always, the easiest way to patch your VMware hosts is with VMware’s vSphere Update Manager. Update Manager, combined with VMware vMotion, lets you safely patch your critical virtual hosts without maintenance windows, service interruptions, or costly downtime.

To be alerted of security advisories as they are released, you can sign up for email notifications. Advisories are also published on the VMware website.

The post NEW VMWARE SECURITY PATCHES AVAILABLE appeared first on eGroup.

What is an ADMX file? From Technet, ADMX files are a standards-based XML file format for storing registry-based policy settings. If you use Group Policy on newer Windows servers, you’re already using them. ADMX files let you create new Group Policy settings that are easy to manage using existing Group Policy tools. This means no more writing scripts just to edit registry settings! ADMX files can be used to manage Vista and newer workstations and Windows Server and newer servers.

With the CustomADMX project, the hard part is already done for you. It comes with a graphical installer and you can choose which software you would like to manage. Here’s just some of the configurable settings:

• 7-Zip
• Control default compression and encryption options for archives
• Manage the Windows context menu appearance
• Java
• Modify the Java update schedule and frequency (or disable entirely)
• Change the user notification about update availability
• Skype
• Disable new version checking
• Limit TCP/UDP ports and connections
• Disable new version checking
• Disable file sharing, screen sharing, Facebook integration, and more
• Adobe Acrobat, Reader, Air, and Updater
• Control update behavior and disable if desired
• Enforce requirements for digital signatures
• Disable Javascript execution in PDFs
• DoubleGIS Mapping Software
• Hide/Show different UI elements
• Manage proxy server settings
• Control product update behavior

You can try all of these features on a test workstation without making any changes to your domain. Choose “Local Mode” when you run the installer to have the ADMX files placed locally.

CustomADMX is open-source (GPLv2), which means it’s available for anyone to use free-of-charge. You can also contribute to the project and share any custom ADMX files you might be using in your environment so that others can benefit.

The post MANAGE THIRD PARTY SOFTWARE WITH CUSTOMADMX appeared first on eGroup.