8 Essential Tips for Virtual Desktop Security

 

1.          Do Not Use Persistent Virtual Desktops

Always use non-persistent virtual desktops. They are more secure because they are refreshed from their original image. Persistent virtual desktops behave like physical desktop PCs and are more susceptible to malware, virus infections, and corruption. OK, now I will admit they may be more difficult to implement and with more requirements, more difficult to manage, but they are the safer bet in the long run.

Even though more time is required for managing a non-persistent refresh-ready virtual desktop environment, this investment is well worth the effort. As a case in point, a school I was working with recently made the smart decisions to virtualize about half of their nearly 1,000 desktops. When a virus attack was detected, they simply advised their users to log off. That action alone was all that was required to completely destroy the virus from all user-accessible VDI desktops, and in only about five minutes. The entire network was spared with only a few servers needing some attention. Any non-virtualized PCs or non-persistent desktops would require considerable time for remediation. So the moral of the story is to virtualize the vast majority of your computing resources. For example, imagine the security you would enjoy if fully 90% of your desktops were virtual and only 10% of resources (typically servers) remained as physical hardware devices.

2.          Maintain Agentless Anti-Virus

Most PCs are running a standard anti-virus package. Don’t scale back on dedicated anti-virus. But if you want to optimize performance, you’ll need an agentless anti-virus solution. In tests, typical anti-virus software decreased storage IOPS performance by as much as 30%.

Consider an agentless option on VMware where a light agent is built into VMware on every virtual machine. NSX or Vshield also provides a structure to use agentless AV and you can put an agentless product like TrendMicro Deep Security or McAfee MOVE on your infrastructure servers. You’ll achieve full-agentless AV scanning on virtual desktops. When a user logs on, they get a fresh virtual machine with no virus. While using the desktop, real-time scans prevent a virus. And when the user logs off, the desktop is refreshed from a clean image. Again, no viruses.

Some customers (it might be a school, municipality, or small business looking to save money) might skip agentless anti-virus, or even skip out on licensing a standard anti-virus package on virtualized machines entirely. This is a poor decision. In these environments, the virus will be introduced, continue to exist, and spread. Even if all users log off, while reducing infection risk dramatically, the potential threat continues to exist. You must maintain real-time anti-virus protection. Agentless options are preferred to eliminate the 30% performance hit.

For the rest of the tips please read my work blog:

http://www.cdillc.com/newsroom/blog/

10 Security Best Practices for Mobile Device Owners

Don’t be alarmed by these statistics. More importantly, don’t become a statistic yourself. I’m sharing a few factoids here to help protect you, as one of the nearly 4.6 billion mobile device users out there (Gartner).

  • Cybercrimes including hacking and theft cost American businesses over $55 million per year (Ponemon Institute)
  • Every month, one in four mobile devices succumbs to some type of cyber threat (Skycure)
  • Last year in the United States alone, over five million smartphones were stolen or lost (Consumer Reports)

Who is responsible for such mayhem? Hackers, of course, and online thieves all over the world.

But who is responsible for protecting your device? You are.

As IT and Networking professionals, we can manage mobile device security around the clock, seven days a week, 365 days a year, but it is you, the mobile device owner or user, who ultimately determines the relative health of your smartphone or tablet and the level of security you want to experience.

To protect your mobile device, follow these recommended best practices:

  1. Lock your device with a passcode: One of the most common ways your identity can be stolen is when your phone is stolen. Lock your device with a password, but do not use common combinations like 1234, 1111. On Android phones you can establish a swipe security pattern. Always set the device to auto-lock when not in use.
  2. Choose the Right Mobile OS for Your Risk Tolerance: Open source integrations, price, and app selection might guide you toward Android or Windows phones; however, Apple devices running iOS are generally more secure. A recent NBC Cybersecurity News article revealed that Google’s Android operating system has become a primary target for hackers because “app marketplaces for Android tend to be less regulated.” Hackers can more easily deploy malicious apps that can be downloaded by anyone. As an example, the article reported that over 180 different types of ransomware were designed to attack Android devices in 2015. If you’re an Android owner, fear not. Consumers who choose Android can still remain safe by being aware of the vulnerabilities and actively applying the other tips in this article.
  3. Monitor Links and Websites Carefully: Take a moment to monitor the links you tap and the websites you open. Links in emails, tweets, and ads are often how cybercriminals compromise your device. If it looks suspicious, it’s best to delete it, especially if you are not familiar with the source of the link. When in doubt, throw it out.

    If you have Android and your friend has an iOS device, and you both have a link you are not sure about opening, open the link on iOS first. This practice allows you to check out the link while lowering your exposure to risks including malware.

  4. Regularly Update Your Mobile OS: Take advantage of fixes in the latest OS patches and versions of apps. These updates include fixes for known vulnerabilities. (To avoid data plan charges, download these updates when connected to a trusted wireless network.) Every few days, and especially whenever you hear news about a new virus, take the time to check for OS updates or app patches.

    In 2016, an iOS 9.x flaw resulted in a vulnerability for iPhone users where simply receiving a certain image could leave the device susceptible to infection. Apple pushed out a patch. A year ago a similar flaw was detected on Android devices; however, the risk to users was significantly greater, impacting 95 percent of nearly one billion Android devices. An expected 90-day patch was late. Meanwhile, the flaw allowed hacking to the maximum extent possible including gaining complete control of the phone, wiping the device, and even accessing apps or secretly turning on the camera. Don’t ignore those prompts to update!

    At this point you may be asking, “Do I need a separate anti-virus app, especially if I use an Android device?” To answer that question, balance your need for security against how much risk you plan on taking with your device. Do you often use public wireless networks and make poor choices with the links you open? For now, you may not need an anti-virus app; however, some early industry trends are showing more anti-virus apps on the horizon.

  5. Do Not Jailbreak Your Smartphone: Reverse engineering and unauthorized modification of your phone (jailbreaking) leaves your phone vulnerable to malware. Even jailbreaking an iOS device leaves it open to infections. If your cousin already customized your device for you, it’s not too late. Restore the OS through the update process or check with an authorized reseller.

For the rest of the tips please read my work blog:

http://www.cdillc.com/newsroom/blog/

Exchange 2010-2016 Database Availability Group (DAG) cluster timeout settings for VMware

Symptom:

Exchange 2010-2016 Database Availability Group (DAG) active database moves between DAG nodes without any reason, when the DAG nodes are VMware Virtual Machines. This may be due to the DAG node being VMotioned by vSphere DRS cluster.

Solution:

The settings below allow you to VMotion without DAG active databases flipping between nodes for no reason.

Although the tip below is mainly useful for Multi-Site DAG clusters, I have seen this flipping happen even within the same site. So, the recommendation is to do these commands on ANY DAG cluster that is running on VMware.

Instructions:

Substitute your DAG name for an example DAG name below, yourDAGname or rpsdag01.

On any Mailbox Role DAG cluster node, open Windows PowerShell with modules loaded.

Image

Type the following command to check current settings:

cluster /cluster:yourDAGname /prop

Note the following Values:

SameSubnetDelay

SameSubnetThreshold

CrossSubnetDelay

CrossSubnetThreshold

Image

Type the following commands to change the timeout settings.

cluster /cluster:yourDAGname /prop SameSubnetDelay=2000

cluster /cluster:yourDAGname /prop SameSubnetThreshold=10

cluster /cluster:yourDAGname /prop CrossSubnetDelay=4000

cluster /cluster:yourDAGname /prop CrossSubnetThreshold=10

Image

Type the command to check that settings took

cluster /cluster:yourDAGname /prop

Image

You ONLY need to run this on ONE DAG node. It will be replicated to ALL the other DAG nodes.

More Information:

See the article below:

http://technet.microsoft.com/en-us/library/dd197562(v=ws.10).aspx

Renaming Virtual Disks (VMDK) in VMware ESXi

Symptom:

You have just cloned a VM, and would like to rename your VMDKs to match the new name of the clone.

When you try to rename a VMDK in the GUI Datastore Browser in vSphere client, you get a message:

“At the moment, vSphere Client does not support the renaming of virtual disks”

How do you go around the message?

Instructions:

  1. Lookup the name of your Datastore and your VM in the GUI.
  2. Start SSH service.
  3. Login as root to your ESXi host.
  4. In a SSH session type the following commands. Substitute the name of your Datastore for STORAGENAME and your VM for VMNAME.
    1. cd /vmfs/volumes/STORAGENAME/VMNAME
  5. Substitute the name of your old VMDK for OLDNAME and your new VMDK for NEWNAME. Remember – everything is case sensitive.
    1. vmkfstools -E ./OLDNAME.vmdk ./NEWNAME.vmdk 

VMware vSphere misidentifies local or SAN-attached SSD drives as non-SSD

Symptom:

You are trying to configure Host Cache Configuration feature in VMware vSphere. The Host Cache feature will swap memory to a local SSD drive, if vSphere encounters memory constraints. It is similar to the famous Windows ReadyBoost.

Host Cache requires an SSD drive, and ESXi will detect the drive type as SSD. If the drive type is NOT SSD, Host Cache Configuration will not be allowed.

However, even though you put in some local SSD drives on the ESXi host, and also have an SSD drive on your storage array coming through, ESXi refuses to recognize the drives as SSD type, and thus refuses to let you use Host Cache.

Solution:

Apply some CLI commands to force ESXi into understanding that your drive is really SSD. Then reconfigure your Host Cache.

Instructions:

Look up the name of the disk and its naa.xxxxxx number in VMware GUI. In our example, we found that the disks that are not properly showing as SSD are:

  • Dell Serial Attached SCSI Disk (naa.600508e0000000002edc6d0e4e3bae0e)  — local SSD
  • DGC Fibre Channel Disk (naa.60060160a89128005a6304b3d121e111) — SAN-attached SSD

Check in the GUI that both show up as non-SSD type.

SSH to ESXi host. Each ESXi host will require you to look up the unique disk names and perform the commands below separately, once per host.

Type the following commands, and find the NAA numbers of your disks.

In the examples below, the relevant information is highlighted in RED.

The commands you need to type are BOLD.

The comments on commands are in GREEN.

———————————————————————————————-

~ # esxcli storage nmp device list

naa.600508e0000000002edc6d0e4e3bae0e

Device Display Name: Dell Serial Attached SCSI Disk (naa.600508e0000000002edc6d0e4e3bae0e)

Storage Array Type: VMW_SATP_LOCAL

Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.

Path Selection Policy: VMW_PSP_FIXED

Path Selection Policy Device Config: {preferred=vmhba0:C1:T0:L0;current=vmhba0:C1:T0:L0}

Path Selection Policy Device Custom Config:

Working Paths: vmhba0:C1:T0:L0

naa.60060160a89128005a6304b3d121e111

Device Display Name: DGC Fibre Channel Disk (naa.60060160a89128005a6304b3d121e111)

Storage Array Type: VMW_SATP_ALUA_CX

Storage Array Type Device Config: {navireg=on, ipfilter=on}{implicit_support=on;explicit_support=on; explicit_allow=on;alua_followover=on;{TPG_id=1,TPG_state=ANO}{TPG_id=2,TPG_state=AO}}

Path Selection Policy: VMW_PSP_RR

Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0;lastPathIndex=1: NumIOsPending=0,numBytesPending=0}

Path Selection Policy Device Custom Config:

Working Paths: vmhba2:C0:T1:L0

naa.60060160a891280066fa0275d221e111

Device Display Name: DGC Fibre Channel Disk (naa.60060160a891280066fa0275d221e111)

Storage Array Type: VMW_SATP_ALUA_CX

Storage Array Type Device Config: {navireg=on, ipfilter=on}{implicit_support=on;explicit_support=on; explicit_allow=on;alua_followover=on;{TPG_id=1,TPG_state=ANO}{TPG_id=2,TPG_state=AO}}

Path Selection Policy: VMW_PSP_RR

Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0;lastPathIndex=1: NumIOsPending=0,numBytesPending=0}

Path Selection Policy Device Custom Config:

Working Paths: vmhba2:C0:T1:L3

———————————————————————————————-

Note that the Storage Array Type is VMW_SATP_LOCAL for the local SSD drive and VMW_SATP_ALUA_CX for the SAN-attached SSD drive.

Now we will check to see if in CLI, ESXi reports the disks as SSD or non-SSD for both disks. Make sure to specify your own NAA number when typing the command.

———————————————————————————————-

~ # esxcli storage core device list –device=naa.600508e0000000002edc6d0e4e3bae0e

naa.600508e0000000002edc6d0e4e3bae0e

Display Name: Dell Serial Attached SCSI Disk (naa.600508e0000000002edc6d0e4e3bae0e)

Has Settable Display Name: true

Size: 94848

Device Type: Direct-Access

Multipath Plugin: NMP

Devfs Path: /vmfs/devices/disks/naa.600508e0000000002edc6d0e4e3bae0e

Vendor: Dell

Model: Virtual Disk

Revision: 1028

SCSI Level: 6

Is Pseudo: false

Status: degraded

Is RDM Capable: true

Is Local: false

Is Removable: false

Is SSD: false

Is Offline: false

Is Perennially Reserved: false

Thin Provisioning Status: unknown

Attached Filters:

VAAI Status: unknown

Other UIDs: vml.0200000000600508e0000000002edc6d0e4e3bae0e566972747561

~ # esxcli storage core device list –device=naa.60060160a89128005a6304b3d121e111

naa.60060160a89128005a6304b3d121e111

Display Name: DGC Fibre Channel Disk (naa.60060160a89128005a6304b3d121e111)

Has Settable Display Name: true

Size: 435200

Device Type: Direct-Access

Multipath Plugin: NMP

Devfs Path: /vmfs/devices/disks/naa.60060160a89128005a6304b3d121e111

Vendor: DGC

Model: VRAID

Revision: 0430

SCSI Level: 4

Is Pseudo: false

Status: on

Is RDM Capable: true

Is Local: false

Is Removable: false

Is SSD: false

Is Offline: false

Is Perennially Reserved: false

Thin Provisioning Status: yes

Attached Filters: VAAI_FILTER

VAAI Status: supported

Other UIDs: vml.020000000060060160a89128005a6304b3d121e111565241494420

———————————————————————————————-

Now we will add a rule to enable SSD on those 2 disks. Make sure to specify your own NAA number when typing the commands.

———————————————————————————————-

~ # esxcli storage nmp satp rule add –satp VMW_SATP_LOCAL –device naa.600508e0000000002edc6d0e4e3bae0e –option=enable_ssd

~ # esxcli storage nmp satp rule add –satp VMW_SATP_ALUA_CX –device naa.60060160a89128005a6304b3d121e111 –option=enable_ssd

———————————————————————————————-

Next, we will check to see that the commands took effect for the 2 disks.

———————————————————————————————-

~ # esxcli storage nmp satp rule list | grep enable_ssd

VMW_SATP_ALUA_CX     naa.60060160a89128005a6304b3d121e111                                                enable_ssd                  user

VMW_SATP_LOCAL       naa.600508e0000000002edc6d0e4e3bae0e                                                enable_ssd                  user

———————————————————————————————-

Then, we will run storage reclaim commands on those 2 disks. Make sure to specify your own NAA number when typing the commands.

———————————————————————————————-

~ # esxcli storage core claiming reclaim -d naa.60060160a89128005a6304b3d121e111

~ # esxcli storage core claiming reclaim -d naa.600508e0000000002edc6d0e4e3bae0e

Unable to unclaim path vmhba0:C1:T0:L0 on device naa.600508e0000000002edc6d0e4e3bae0e. Some paths may be left in an unclaimed state. You will need to claim them manually using the appropriate commands or wait for periodic path claiming to reclaim them automatically.

———————————————————————————————-

If you get the error message above, that’s OK. It takes time for the reclaim command to work.

You can check in the CLI by running the command below and looking for “Is SSD: false”

———————————————————————————————-

~ # esxcli storage core device list –device=naa.600508e0000000002edc6d0e4e3bae0e

naa.600508e0000000002edc6d0e4e3bae0e

Display Name: Dell Serial Attached SCSI Disk (naa.600508e0000000002edc6d0e4e3bae0e)

Has Settable Display Name: true

Size: 94848

Device Type: Direct-Access

Multipath Plugin: NMP

Devfs Path: /vmfs/devices/disks/naa.600508e0000000002edc6d0e4e3bae0e

Vendor: Dell

Model: Virtual Disk

Revision: 1028

SCSI Level: 6

Is Pseudo: false

Status: degraded

Is RDM Capable: true

Is Local: false

Is Removable: false

Is SSD: false

Is Offline: false

Is Perennially Reserved: false

Thin Provisioning Status: unknown

Attached Filters:

VAAI Status: unknown

Other UIDs: vml.0200000000600508e0000000002edc6d0e4e3bae0e566972747561

———————————————————————————————-

Check in the vSphere Client GUI. Rescan storage.

If it still does NOT say SSD, reboot the ESXi host. 

Then look in the GUI and rerun the command below.

———————————————————————————————-

~ # esxcli storage core device list —device=naa.60060160a89128005a6304b3d121e111

naa.60060160a89128005a6304b3d121e111

Display Name: DGC Fibre Channel Disk (naa.60060160a89128005a6304b3d121e111)

Has Settable Display Name: true

Size: 435200

Device Type: Direct-Access

Multipath Plugin: NMP

Devfs Path: /vmfs/devices/disks/naa.60060160a89128005a6304b3d121e111

Vendor: DGC

Model: VRAID

Revision: 0430

SCSI Level: 4

Is Pseudo: false

Status: on

Is RDM Capable: true

Is Local: false

Is Removable: false

Is SSD: true

Is Offline: false

Is Perennially Reserved: false

Thin Provisioning Status: yes

Attached Filters: VAAI_FILTER

VAAI Status: supported

Other UIDs: vml.020000000060060160a89128005a6304b3d121e111565241494420

———————————————————————————————-

If it still does NOT say SSD, you need to wait. Eventually, the command works and displays as SSD in CLI and the GUI. 

More Information:

See the article below:

Swap to host cache aka swap to SSD?

Enable Microsoft Exchange 2010-2016 DAC mode

Description:

Datacenter Activation Coordination (DAC) mode is a property setting for a database availability group (DAG).

DAC mode is disabled by default and should be enabled for all DAGs with 2 or more members that use continuous replication.

That means the majority of Exchange DAG deployments need the DAC mode.

The DAC is most useful in a multi-datacenter configuration to prevent split brain syndrome, a condition that occurs when all networks fail, and DAG members can’t receive heartbeat signals from each other.

However, I suggest you always enable the DAC.

If you enable the DAC and you need to recover, the recovery takes less commands on the command line. Only the following commandlets will be necessary:

Stop-DatabaseAvailabilityGroup

Restore-DatabaseAvailabilityGroup

Start-DatabaseAvailabilityGroup

Also, if you did NOT enable the DAC, you cannot do so if you have a failure. The DAC must be enabled ahead of time.

Instructions:

Here is how to enable the DAC mode:

1. Go to Exchange Management Shell

2. Type the following, where DAG2 is your DAG name:

Set-DatabaseAvailabilityGroup -Identity DAG2 -DatacenterActivationMode DagOnly

More Information:

For more information, read this article:

http://technet.microsoft.com/en-us/library/dd979790.aspx

What’s next for Virtual Desktop Infrastructure?

Greetings CIOs, IT Managers, VM-ers, Cisco-ites, Microsoftians, and all other End-Users out there… Yury here. Yury Magalif. Inviting you now to take another virtual trip with me to the cloud, or at least to your data center. As Practice Manager at CDI, your company is depending on my team of seven (plus or minus a consultant or two) to manage the implementation of virtualized computing including hardware, software, equipment, service optimization, monitoring, provisioning, etc. And you thought we were sitting behind the helpdesk and concerned only with front-end connectivity. Haha (still laughing) that’s a good one!

VDI: OUR JOURNEY BEGINS HERE
Allow me to paint a simple picture and add a splash of math to illustrate why your CIO expects so much from me and my team. Your company posted double-digit revenue growth for three years running and somehow, now, in Q2 of year four, finds itself in a long fourth down and 20 situation. (What? You don’t understand American football analogies? Okay, in the international language of auto-racing, we are 20 laps behind and just lost a wheel.) One thousand employees need new laptops, docking stations, flat panel displays, and related hardware. Complicating the matter are annual software licensing fees for a group of 200 but with only five simultaneous concurrent users worldwide. At $1,500 per user times 1,000, plus the $100 fee, your CIO has to decide how it will explain to the board that it plans to spend another 1.5 million dollars on IT just after Q1 closed down 40 percent and Q2 is looking to be even worse.

To read the rest of this blog, where I try something different, please go to my work blog page:

http://www.cdillc.com/whats-next-virtual-desktop-infrastructure/

Assessing your Infrastructure for VDI with real data – Part 2 of 2 – Analysis

For VSI, we established that using analysis tools was a necessity, and VMware provided wonderful Capacity Planner tool. However, it soon became evident that for VDI, it is even more important to use analysis tools. That is because for VDI, when you buy hardware and software, the investment is generally higher. You need a lot more, faster storage. You need many servers and a fast network. So the margin of error is smaller.

Consequently, using Liquidware FIT or Lakeside SysTrack is essential. There are now a few more tools on the market, like ControlUp or Login PI. However, the new entrants have not been battle tested yet.

So how do you analyze your physical desktops for VDI?

First, buy a license for the Liquidware FIT tool (per user, inexpensive), or buy an engagement from your friendly Valued Added Reseller or Integrator who is a Liquidware partner. If you buy a service from a partner, then usually up to 250 desktop license will be included with the service.

Here, I will talk about services of the partner because that is what I do. However, if you are doing this yourself, just apply the same steps.

You will need to provide your partner’s engineer with space for 2 small Liquidware virtual appliances. The only gotcha is that you want them on the fastest storage you have (SSD preferable). That is because on slower storage, it takes much longer to process any analysis or reports.

The engineer will come and install the 2 appliances into your vSphere. Then, the engineer will give you an EXE or MSI with an agent. Usually, you can use the same mechanism you already use to install software on your desktops to distribute the agent. For example, distribution tools like Microsoft SCCM, Symantec Altiris, LANDesk, and even Microsoft Group Policy will all be good. If you don’t have a mechanism for software distribution, then your engineer can use a script to install the agents on all PCs.

Make sure to choose a subset of your PCs, and at least some from each possible group of similar users (Accounting, Sales, IT, etc.). Your sample size could be about 10-25% of total user count. Obviously, the higher the analysis percentage, the more accuracy you get. But the goal here is not 100% accuracy – it’s impossible to achieve 100%. Assessment and performance analysis is an art as much as a science. Thus, you need just enough users to get a ballpark estimate of what hardware you need to buy. Also, run the assessment for 1 month preferably, or at a bare minimum 2 weeks. The time of the start of the data collection above should start from the time you deploy your last user with the Liquidware agent.

Your partner engineer will need remote access, if possible, to check on the progress of the installation. First, the engineer will check if the agents are reporting successfully back to the Liquidware appliances. During the month, the engineer will make sure agents are reporting and data can be extracted from the appliance.

In the middle of the assessment, engineer will do a so-called “normalization” of the data. That is to make sure the results are compatible with rules of thumb for analysis. If necessary, the engineer will readjust thresholds and recalculate the data back to the beginning.

At the end of 30 days, the engineer will generate a machine-made report on the overall performance metrics, and will present the report to you.

At some partners, for an extra service price, the engineer will go further, and will analyze the report for the amount and performance parameters of hardware you need. In addition, the engineer will create a written report and present all the data to you.

In either case, you will know which desktops have the best score for virtualization, and which ones you should not virtualize. If you go with more advanced report services from your partner, then you will also understand how to map the results to hardware and further insights.

One way of mitigating bad VDI sizings is to also use a load simulation tool like LoginVSI. However, LoginVSI is only useful for clients who can afford to buy similar equipment for the lab that they will buy for production. Using LoginVSI, you can test robotic (fake) users doing tasks that normal users will do in VDI. LoginVSI allows you to have a ballpark hardware number that is good. However, the LoginVSI number does not have real user experience data. For that, you need tools like Liquidware FIT and associated work to determine proper VDI strategy.

Understanding what your current user experience is, and also how that experience could be accommodated with virtual desktops is essential to VDI. You should do this assessment before buying your hardware. Doing an assessment ensures that your users get the same experience or better on the virtual desktop as they have on the physical desktop (the holy grail of VDI).

Assessing your Infrastructure for VDI with real data – Part 1 of 2 – History

It is now a common rule of thumb that when you are building Virtual Server Infrastructure (VSI), you must assess your physical environment with analysis tools. The analysis tools show you how to fit your physical workloads onto virtual machines and hosts.

The golden standard in analysis tools is VMware’s Capacity Planner. Capacity Planner used to be made by a company called AOG. AOG was analyzing not just for physical to virtual migrations, but was doing overall performance analysis of different aspects of the system. AOG was one of the first agentless data collections tools. Agentless was better because you did not have to touch each system in a drastic way, there was less chance of drivers going bad or performance impact to the target system.

Thus, AOG partnered with HP and other manufacturers, and was doing free assessments for their customers, while getting paid by the manufacturer on the backend. AOG tried to sell itself to HP, but HP, stupidly, did not buy AOG. Suddenly, VMware came from nowhere and snapped up AOG. VMware at the time needed an analysis tool to help customers migrate to the virtual infrastructure faster.

When VMware bought AOG, VMware dropped AOG’s other analysis business, and made AOG a free tool for partners to analyze migrations to the virtual infrastructure. It was a shame, because AOG’s tool, renamed to Capacity Planner, was really good. Capacity Planner relies solely on Windows Management Instrumentation (WMI) functions that is already built into Windows and is collecting information all the time. Normally, WMI discards information like performance, unless it is collected somewhere by choice. Capacity Planner just enabled that choice, and collected WMI performance and configuration data from each physical machine.

When VMware entered the Virtual Desktop Infrastructure (VDI) business with Horizon View, it lacked major pieces in the VDI ecosphere. One of the pieces was profile management, another piece was planning and analysis, another piece was monitoring. Immediately, numerous companies sprang to life to help VMware fill the need. Liquidware Labs (where the founder worked for VMware) was the first to come up with a robust planning and analysis tool in Stratusphere FIT, then with monitoring tool in Stratusphere UX. Lakeside SysTrack came on the scene. VMware used both internally, although the preference was for Liquidware.

Finally, VMware realized that the lack of analysis tool for VDI, made by VMware, was hindering them. But what they failed to realize, was that such tool already existed at VMware for years – Capacity Planner. The Capacity Planner team was neglected, so rarely would any updates were done to the tool. However, since Capacity Planner could already analyze physical machines for performance, it was easy to modify the code to collect information on virtualizing physical desktops, in addition to servers.

Capacity Planner code was eventually updated with desktops analysis. All VMware partners were jumping with joy – we now had a great tool and we did not have to relearn any new software. I remember that I eagerly collected my first data, and began to analyze the data. After analysis, the tool told me I needed something like twenty physical servers to hold 400 virtual desktops. Twenty desktops per server? That sounded wasteful. I was a beginner VDI specialist then, so I trusted the tool but still had doubts. Then I did a few more passes at the analysis, and kept getting wildly different numbers. Trusting my gut instinct, I decided to redo one analysis with Liquidware FIT.

Of course, Liquidware FIT has agents, so I used it, but always thought that it would be nice not to have agents. So VMware’s addition of desktop analysis to agentless Capacity Planner was very welcome. So, back to my analysis, after running Liquidware FIT, I came up with completely different numbers. I don’t remember what they were – perhaps 60 desktops per physical server, or something else. But what I do remember was that Liquidware’s analysis made sense, where Capacity Planner did not. My suspicions about Capacity Planner as a tool were confirmed by VMware’s own VDI staff, who, when asked if they use Capacity Planner to size VDI said, “For VDI, avoid Cap Planner like the plague, and keep using Liquidware FIT.”

As a result, I kept using Liquidware FIT since then, and never looked back. While FIT does have agents, now I understand that getting metrics like Application load times and User Login delay is not possible without agents. That is because Windows does not include such metrics in WMI. Therefore, a rich agent is able to pick up many more user experience items, and thus do much better modeling.

Collateral for my presentation at the Workshop of the Association of Environmental Authorities of NJ (AEANJ)

I was glad for a chance to present at the Workshop of the Association of Environmental Authorities of NJ (AEANJ). There were great questions from the audience.

Thank you to attendees, Leon McBride for the invitation, Peggy Gallos, Karen Burris, and to my colleague Lucy Valle for videotaping.

My presentation is called “Data Portability, Data Security, and Data Availability in Cloud Services”

Here are the collateral files for the session:

Slides:

AEANJ Workshop 2016-slides-YuryMagalif

Video:

AEANJ Workshop 2016 Video – Yury Magalif