Author Archives: VMware Professional Services

New Technology Implementation Plan: Start by Stepping Back

Jeremy Carter headshotBy Jeremy Carter, VMware Senior Consultant

I’ve been working on a customer engagement recently that takes advantage of vCloud Automation Center (vCAC), which is designed to centralize and automate key IT activities, freeing the organization to focus on the needs of internal and external customers.

In our deployment of vCAC, I’ve been reminded of a key principal of IT and business transformation: The technology is only part of the process. Often a shift in technology requires a period of assessment and realignment that is as valuable as the technology itself.

When the VMware Professional Services team is brought in for an engagement, the company wants to get the best return on its investment, so the IT team is receptive to our schedule of meetings and stock-taking. But every IT organization will benefit by starting their new technology implementation plan by stepping back to survey the systems in place before integrating a new one.

We put a lot of emphasis on investigating how things are currently done, often starting by asking the teams to draw their processes, for creating a virtual machine, for instance. Frequently we find they have two or three different processes in place, depending on who’s making request. This is especially common in government and higher education, where each department is likely to have it’s own IT team and strategy.

The unfortunate fact is that automation still scares people, thinking they’re going to be out of a job. On the contrary, if you look at any IT organization out there, you’ll see that it’s overwhelmed with tasks, many of which are never getting done. Automation can give them time back to focus on what’s important to their customers.

A new implementation is a perfect opportunity to look at which processes are working the best and align all the teams to them. When a team sees that they’ll be able to provide a better experience and quicker turnaround, their resistance to automation often fades.

And luckily vCAC provides enough flexibility that users don’t have to adopt exactly the same systems across the organization. With a college I worked with recently, we were able to build on what teams are already doing. Next we focused on handoff systems to cut down on the number of emails flying around: one for DNS, another to install the OS, etc.

This process—of assessing current processes, building in automation and consistency, and then refocusing on customer needs—is undeniably valuable. But it does take time. It’s worth putting these reassessments on the calendar every 6 or 12 months; if that doesn’t work, I recommend taking the opportunity presented by the implementation of a new technology to keep moving toward the best your organization can be.


Jeremy Carter is a Senior Consultant with VMware and is focused on the Software Defined Data Center (SDDC). He has special expertise in cloud infrastructure and automation, and BCDR. Over his 14 years in IT he has gained a variety of experience as an architect, DBA, and developer. Prior to joining VMware, Jeremy was a Principal Architect at one of the largest VMware service providers. 

 

Horizon Workspace Tips: Increased Performance for the Internal Database

By Dale Carter, Consulting Architect, End User Computing

During my time deploying VMware Horizon Workspace 1.5 to a very large corporation with a very large Active Directory (AD) infrastructure, I noticed that the internal Horizon database would have performance issues when syncing the database with AD.

After discussing the issues with VMware Engineering we found a number of ways to improve performance of the database during these times. Below I’ve outlined the changes I made to Horizon Workspace to increase performance for the internal database.

I should note that the VMware best practice for production environments is to use an external database. However in some deployments customers still prefer to use the internal database; for instance, for a Pilot deployment.

Service-va sizing

It is very important to size this VM correctly; this is where the database sits and the VM that will be doing most of the work. It is very important that this VM not be undersized. The following is a recommended size for the service-va, but you should monitor this VM and change as needed.

  • 6 x CPUs
  • 16GBs x RAM

Database Audit Queue

If you have a very large users population, then you will need to increase the audit queue size to handle the huge deluge of messages generated by entitling a large volume of users to an application at once. VMware recommends that the queue be at least three times the number of users. Make this change to the database with the following SQL:

  1. Log in to the console on the service-va as root
  2. Stop the Horizon Frontend service

service horizon-frontend stop

  1. Start PSQL as horizon user.  You will be prompted for a password.

psql -d “saas” -U horizon

  1. Increase Audit queue size

INSERT INTO “GlobalConfigParameters” (“strKey”, “idEncryptionMethod”, “strData”)

VALUES (‘maxAuditsInQueueBeforeDropping’, ‘3’, ‘125000’);

  1. Exit

\q

  1. Start the Horizon Frontend service

service horizon-frontend start.

  1. Start the Horizon Frontend service

service horizon-frontend start.

Adding Indexes to the Database

A number of indexes can be added to the internal database to improve performance when dealing with a large number of users.

The following commands can be run on the service-va to add these indexes

  1. Log in to the console on the service-va as root
  2. Stop the Horizon Frontend service

service horizon-frontend stop

  1. Start PSQL as horizon user.  You will be prompted for a password.

psql -d “saas” -U horizon

  1. Create an index on the UserEntitlement table

CREATE INDEX userentitlement_resourceuuid

ON “UserEntitlement”

USING btree

(“resourceUuid” COLLATE pg_catalog.”default”);

  1. Create 2nd index

CREATE INDEX userentitlement_userid

ON “UserEntitlement”

USING btree

(“userId”);

  1. Exit

\q

  1. Start the Horizon Frontend service

service horizon-frontend start.

I would also like to point out that these performance issues have been fixed in the up and coming Horizon 1.8 release.  For now, though, I hope this helps. Feel free to leave any questions in the comments of this post.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

Think Like a Service Provider, Build in vCenter Resilience

Jeremy Carter headshot By Jeremy Carter, VMware Senior Consultant

When I’m working on a customer engagement, we always strategize to ensure resiliency and failover protection for vCenter Automation Center (vCAC). While these considerations continue to be top priorities, there is another question that seems to be coming up more and more: “What about vCenter?”

vCenter has long been thought of as the constant, the unshakable foundation that supports business differentiators like vCAC. Although we’re happy for that reputation, it’s important for IT organizations to take the appropriate actions to protect all components up and down the stack

This is increasingly necessary as organizations move into an IT-as-a-Service model. As more parts of the business come to rely on the services that IT provides, IT must be sure to deliver on its SLAs—and that means improved resilience for vCenter as well as the applications that sit on top of it.

Our customers have found vCenter Server Heartbeat to be an essential tool to support this effort. Heartbeat allows IT to monitor and protect vCenter from a centralized easy-to-use web interface and protects against application or operator errors, operating system or hardware failure and external. In addition to protecting against the unplanned downtime, it provides improved control during planned downtime, such as during Windows updates, allowing patches without vCenter downtime.

In the past, Heartbeat was most popular with service providers who needed to securely open up vCenter to customers. Now that more IT organizations are becoming service providers themselves, I encourage them to support their internal customers at the same level and make sure vCenter resilience and protection is part of the plan.


Jeremy Carter is a VMware Senior Consultant with special expertise in BCDR and cloud automation. Although he joined VMware just three months ago, he has worked in the IT industry for more than 14 years.

Successful IaaS Deployment Requires Flexibility & Alignment

Alex SalicrupBy Alex Salicrup, IT Transformation Strategist

When the CEO of a global food retailer announces his goal to triple revenues in five years, the IT organization knows it’s time to step up its plans to overhaul the IT infrastructure.

That’s just what happened in a recent customer engagement where we helped the IT organization automate provisioning, eliminate the need for a significant increase in headcount, and enable a new service provider approach to support their software-defined data center.

The engagement started off with a very aggressive, short interval, cloud service implementation plan. But halfway through the engagement we had to quickly pivot when the CIO accelerated a major service offering commitment to the business. Because of that course change, this engagement is a great example of why an IT organization’s journey needs to build toward an agile infrastructure and cross-team alignment to ensure success—even in the face of unexpected change.

The Goal

The IT department was eager to adopt an IT-as-a-Service (ITaaS) model to support its transformation for two key reasons:

  1. It would help keep IT operations humming as the company continued to expand and innovate.
  2. It would showcase the IT team’s strategic value by improving IT services to other organizations.

We first worked with the customer to establish their end-state vision, complete with a timeline that would allow employees to learn the new technology and gradually get comfortable with the ITaaS approach. The client also chose to start by introducing Infrastructure-as-a-Service (IaaS) through a pilot to automate provisioning. Four weeks into the engagement, the CIO made the announcement.

A key business unit had been preparing to roll out changes to the company’s public website and needed an infrastructure platform for their testing, development, and QA efforts. Although the business unit’s IT staff was looking at a external cloud service provider’s infrastructure platform, the CIO stood firm: The pre-launch testing was to be conducted on the new IaaS foundation currently being built.

The original plan to gradually build project momentum instantly switched to a full-out sprint. The new plan was to execute on multiple project points simultaneously, rather than one step at a time. This is where our program design that combines organizational with technology development to meet the desired end-state IT transformation was key.

While we addressed the requirements for the new infrastructure, the customer’s IT infrastructure team continued to develop new functionality for the service offering, which would provide additional capabilities on top of the core infrastructure offering. Knowing success depended on a close partnership with the IT team, as well as buy-in across the business, we implemented a series of three workshops, wrapping up with a clear plan to move forward.

1. Organizational Readiness Assessment

Our team began by interviewing leaders in 30 functional areas of the IT business to score the retailer on its current level of efficiency, automation, and documentation. The areas with lower scores showed us where we needed to make improvements as we created the new infrastructure.

2. Organizational Readiness Discovery Sessions

These formal meetings with the retailer’s management team helped us reach an in-depth understanding of how the business unit operated its IT business, technically as well as operationally. After each concentrated session, we crafted a summary that outlined progress and achievements.

3. Validation Sessions

Conducted in parallel, these provided an opportunity to share observations from the previous sessions and compare notes. This also allowed the internal IT team to provide recommendations and alternatives early on and contribute to the decision-making process for next steps.

4. Validation Report

Finally, we presented a roadmap and plan for what we would build and how it would be done.

Simultaneously, we focused on integrating the organization’s diverse provisioning technologies using the findings from our readiness assessment. To get the company closer to its goal—to shorten provisioning from 10 weeks to 10 minutes—we needed to free IT from its current method of manually inputting information into one system at a time, one step at a time. After outlining a plan and identifying process areas with opportunities for automation, we successfully integrated directory and collaboration applications, security tools, and all of the IT management systems with a compressed schedule and minimum hiccups.

This project was particularly satisfying. Given the scale and the time pressure, everyone was in sync—including the customer. And it reminded me that with careful assessment, planning, and socialization, along with a flexible mindset, IT can adapt to rapid changes—from outside or inside the business.


Alex Salicrup is currently VMware’s Program Manager for the IT Transformation Programs effort at a major global food retailer. He has more than 17 years experience in the IT and telecommunications Industry and has held an array of positions within service providers. Read more insights from Alex on the VMware Accelerate Blog.

BCDR Strategy: Three Critical Questions

Jeremy Carter headshotBy Jeremy Carter, VMware Senior Consultant

Organizations in every industry are increasingly dependent on technology, making increased resiliency and decreased downtime a critical priority. In fact, Forrester cites resiliency as the number three overall infrastructure priority this year.

A business continuity solution that utilizes the virtual infrastructure, like the one VMware offers, can greatly simplify the process, though IT still needs to understand how all the pieces of their business continuity and disaster recover (BCDR) strategy fit together.

I often run up against the expectation of a one-size-fits-all BCDR solution. Instead it’s helpful to understand the three key facets of IT resilience—data protection, local application availability, and site application availability—and how different tools protect each one, for both planned and unplanned downtime (see the diagram below). If you’d like to learn more on that front, there is a free two-part webcast coming up that I recommend you sign up for here.

As important as it is to find the right tool, you only know a tool is “right” if it meets a set of clearly defined business objectives. That’s why I recommend that organizations start their BCDR planning with a few high-level questions to help them assess their business needs.

1. What is truly critical?

Almost everyone’s initial response is that they want to protect everything, but when you look at the trade-off in complexity, you’ll quickly recognize the need to prioritize.

An important (and sometimes overlooked) step in this decision-making process is to check in with the business users who will be affected. They might surprise you. For instance, I was working with a government organization where IT assumed everything was super critical. When we talked to the business users, it turned out they had all of their information on paper forms that would then be entered into the computer. If the computer went down, they would lose almost no data.

On the other hand, the organization’s 911 center’s data was extremely critical and any downtime or loss of data could have catastrophic consequences. Understanding what could be deprioritized allowed us to spend the time (and money) properly protecting the 911 center.

As we move further into cloud computing, another option is emerging: Let the application owners decide at deployment. With tools like vCloud Automation Center (vCAC), we can define resources with differing service levels. An oil company I recently worked with integrated SRM with vCAC so that any applications deployed into Gold or Silver tiers would be protected by SRM.

Planned Downtime Unplanned Downtime VMware Data Protection2. Which failures are you preventing?

Each level of the data center has its preferred method of protection, although all areas also need to work together. If you’re concerned about preventing failures within the data center, maybe you rely on HA and App HA; however, if you want to protect the entire datacenter, you’ll need SRM and vSphere Replication (again, see chart).

3. RTO, RPO, MTD?

Another helpful step in choosing the best BCDR strategy is to define a recovery time objective (RTO), recovery point objective (RPO) and maximum tolerable downtime (MTD) for both critical and non-critical systems.

These objectives are often dictated by a contract or legal regulations that require a certain percentage of uptime. When established internally, they should take many factors into account, including if data exists elsewhere and the repercussions of downtime, especially financial ones.

The final step in the implementation of any successful IT strategy is not a question, but rather an ongoing diligence. Remember that your BCDR strategy is a living entity—you can’t just set it and forget it. Every time you make a change to the infrastructure or add a new application, you’ll need to work it into the BCDR plans. But I hope that each update will be a little easier now that you know the right questions to ask.


VMware-WebcastWant to learn more about building out a holistic business continuity and disaster recovery strategy?
Join these two great (free) webcasts that are right around the corner.

Implementing a Holistic BC/DR Strategy with VMware – Part One
Tuesday, February 18 – 10 a.m. PST

Technical Deep Dive – Implementing a Holistic BC/DR Strategy with VMware – Part Two
Tuesday, February 25 – 10 a.m. PST


Jeremy Carter is a VMware Senior Consultant with special expertise in BCDR and cloud automation. Although he joined VMware just three months ago, he has worked in the IT industry for more than 14 years. 

4 Key Steps for Successful Infrastructure Implementation

By Martijn Baecke, VMware Senior Consultant

As a follow-up to the infographic Bret Connor posted last week about the ways VMware Professional Services collaborate with clients, I thought I would share some tips from my experience working with a client. Whether you’re leading your own IT engagement or working internally, I hope this will help you start build a strong foundation for your next implementation.

The Client

This engagement was with a European ministry providing IT services to five government agencies, and needing to extend its reach to eleven. Its goal was to implement a single infrastructure able to deliver shared services where needed; however, its two data centers were already approaching capacity.

Our charter was to design the infrastructure for the ministry’s current needs—consolidating agencies into a single IT platform—while also developing a roadmap for migration to a cloud architecture in two years. Acting on the advice of VMware, the ministry decided to replace its aging hardware with blade servers, upgrade to the latest version of vSphere, and virtualize all major business applications.

1. Discovery

To understand where you want to go, it’s important to understand where you’re starting from. That’s why one of our first steps was to document in detail the ministry’s current architecture, along with business requirements, technical constraints, and other design parameters.

From there we were able to narrow in on a few key goals:

  1. Simplify data center management
  2. Automate important processes
  3. Improve resiliency
  4. Respond faster to shifting priorities

2. Research & Buy-in

Early on, we hosted several workshops to determine needs and characteristics according to stakeholders at every level—users, managers, directors, and above. Making sure to gather input from a broad cross section helps avoid late-stage direction shifts, and also helps gain buy-in for the chosen solution.

For more about gaining buy-in from the highest levels and finding someone to champion your cause, I recommend Samuel Denton-Giles’ excellent post from December.

3. Planning

Considering the goals of the IT organization as well as other ministry departments, we were able to help them plan both a near-term refresh and a longer-term roadmap to the cloud. The most significant high-level recommendation was to adopt a building-block architecture: a modular system sized to fit existing needs that could easily scale to match future demand.

4. Education & Hand-off

To help avoid vision drift after hand-off, we were careful to map each requirement that came up in the initial forum to a specific technology we helped put in place to support it. Our consulting team also shared best practices and technology standards with the ministry’s IT staff in presentations and informal discussions.

At the end of the engagement, the ministry’s IT managers had a much clearer understanding of how the cloud would impact day-to-day operations, from help desk operations and staff scheduling to management and training. Ultimately this helped the ministry’s IT staff approach its future cloud expansion with confidence, knowing they would avoid expensive, disruptive missteps.


Martijn Baecke is a Senior Consultant for VMware Professional Services in Northern EMEA. He has 10+ years experience in advising and consulting with large enterprise companies around IT infrastructure. He is a VMware Certified Design eXpert (VCDX #103) and you can find more insights on his personal blog, Think©Loud.

Inside VMware Professional Services – Connect, Empower, Focus

From Bret Connor

Happy New Year! As vice president of VMware Professional Services for the Americas delivery team, I am fortunate to work with and lead a team of gifted, creative and downright smart professionals. How do we help our customers? Simple—we deliver faster results while cutting costs and accelerating business breakthroughs that have a material impact on your top line. I can go on but instead, we produced a visual guide that tells the story of the three cornerstone principles that differentiate our work from our competitors. Enjoy!

Creating Purpose-Built vSphere Clusters

By Sunny Dua, Senior Technology Consultant at VMware 

I recently had an opportunity to present at vForum 2013 in Mumbai, the Financial Capital of India. With more than 3,000 participants and two days of events, it was definitely one of the biggest customer events in India. Along with my team, I represented VMware Professional Services and presented on the following topic: “Architecting vSphere Environments – Everything you wanted to know!”

When we finalized the topic, I realized that presenting this topic in 45 minutes is next to impossible. With the amount of complexity that goes into Architecting a vSphere Environment, one could easily write an entire book. However, the task at hand was to keep it to the length of a presentation.

As I started planning the slides, I decided to look at the architectural decisions, which in my experience are the Most Important Ones, since they can make or break the virtual infrastructure. My other criterion was to ensure I talk about the Grey Areas where I always see uncertainty. This uncertainty can transform a good design into a bad one.

At the end I was able to come out with a final presentation which was received very well by the attendees. I thought of sharing the content with the entire community through this blog post. This is part 1, where I will give you some key design considerations for designing vSphere Clusters.

Before I begin, I also want to give the credit to a number of VMware experts in the community. Their books, blogs and the discussions I have had with them in the past helped me in creating this content. This includes books and blogs by DuncanFrankForbes GuthrieScott LoweCormac Hogan and some fantastic discussions with Michael Webster earlier this year.

Before we begin here is a small graphical disclaimer:

And here are my thoughts on creating vSphere Clusters.

The message behind the slide above is to create vSphere Clusters based on the purpose they need to fulfill in the IT landscape of your organization.

Management Cluster

The management cluster refers here to a 2- to 3-host ESXi host used by the IT team to primarily host all the workloads that are used to build up a vSphere Infrastructure. This includes VMs such as vCenter Server, Database Server, vCOps, SRM, vSphere Replication Appliance, VMA Appliance, Chargeback Manager, etc. This cluster can also host other infrastructure components such as active directory, backup servers, anti-virus etc. This approach has multiple benefits such as:

  • Security due to isolation of management workloads from production workloads. This gives complete control to the IT team on the workloads, which are critical to manage the environment.
  • Ease of upgrading the vSphere Environment and related components without impacting the production workloads.
  • Ease of troubleshooting issues within these components since the resources such as compute, storage, and network are isolated and dedicated for this cluster.
  • The number of ESXi hosts in a cluster will impact your consolidation ratios in most cases. As a rule of thumb, you will always consider one ESXi host in a 4-node cluster for HA failover (assuming), but you could also do the same on a 8-node cluster, which ideally saves one ESXi host for you for running additional workloads. Yes, the HA calculations matter and they can be either on the basis of slot size or percentage of resources.
  • Always consider at least one host as a failover limit per 8 to 10 ESXi servers. So in a 16 node cluster, do not stick with only one host for failover, look for at least taking this number to two. This is to ensure that you cover the risk as much as possible by providing an additional node for failover scenarios.
  • Setting up large clusters comes with its benefits, such as higher consolidation ratios etc. But they might have a downside as well if you do not have enterprise-class or rightly sized storage in your infrastructure. Remember, if a datastore is presented to a 16-node or a 32-node cluster, and if the VMs on that datastore are spread across the cluster, chances are you might get into contention for SCSI locking. If you are using VAAI, this will be reduced by ATS; however, try to start small and grow gradually to see if your storage behavior is not being impacted.
  •  Having separate ESXi servers for DMZ workloads is OLD SCHOOL. This was done to create physical boundaries between servers. This practice is a true burden carried over from the physical world to the virtual. It’s time to shed that load and make use of mature technologies, such as VLANs to create logical isolation zones between internal and external networks. Worst case, you might want to use separate network cards and physical network fabric, but you can still run on the same ESXi server, giving you better consolidation ratios and ensuring the level of security required in an enterprise.

Quick Tip: Ensure that this cluster is a minimum 2-node cluster for vSphere HA to protect workloads in case one host goes down. A 3-node management cluster would be ideal, since you would have the option of running maintenance tasks on ESXi servers without having to disable HA. You might want to consider using VSAN for this infrastructure as this is the primary use case that both Rawlinson & Cormac suggest. Remember, VSAN is in beta right now, so make your choices accordingly.

Production Clusters

As the name suggests this cluster would host all your production workloads. This cluster is the heart of your organization as it hosts the business applications, databases, and web services. This is what gives you the job of being a VMware architect or a virtualization admin.

Here are a few pointers to keep in mind while creating production clusters:

  • The number of ESXi hosts in a cluster will impact you consolidation ratios in most of the cases. As a rule of thumb, you will always consider one ESXi host in a 4-node cluster for HA failover (assuming), but you could also do the same on a 8-node cluster, which ideally saves one ESXi host for you for running additional workloads. Yes, the HA calculations matter and they can be either on the basis of slot size or percentage of resources.
  • Always consider at least 1 host as a failover limit per 8 to 10 ESXi servers. So in a 16 node cluster, do not stick with only 1 host for failover, look for at least taking this number to 2. This is to ensure that you cover the risk as much as possible by providing additional node for failover scenarios
  • Setting up large clusters comes with their benefits such as higher consolidation ratios etc., they might have a downside as well if you do not have the enterprise class or rightly sized storage in your infrastructure. Remember, if a Datastore is presented to a 16 Node or a 32 Node cluster, and on top of that, if the VMs on that datastore are spread across the cluster, chances that you might get into contention for SCSI locking. If you are using VAAI this will be reduced by ATS, however try to start with small and grow gradually to see if your storage behavior is not being impacted.

Having separate ESXI servers for DMZ workloads is OLD SCHOOL. This was done to create physical boundaries between servers. This practice is a true burden which is carried over from physical world to virtual. It’s time to shed that load and make use of mature technologies such as VLANs to create logical isolation zones between internal and external networks. In worst case, you might want to use separate network cards and physical network fabric but you can still run on the same ESXi server which gives you better consolidation ratios and ensures the level of security which is required in an enterprise.

Island Clusters

They sound fancy but the concept of island clusters is fairly simple: run islands of ESXi servers (small groups) that can host workloads with special license requirements. Although I do not appreciate how some vendors try to apply illogical licensing policies on their applications, middle-ware and databases, this is a great way of avoiding all the hustle and bustle created by sales folks. Some examples of island clusters would include:

  • Running Oracle Databases/Middleware/Applications on their dedicated clusters. This will not only ensure that you are able to consolidate more and more on a small cluster of ESXi hosts and save money but also ensures that you zip the mouth of your friendly sales guy by being in what they think is license compliance.
  • I have customers who have used island clusters of operating systems such as Windows. This also helps you save on those datacenter, enterprise, or standard editions of Windows OS.
  • Another important benefit of this approach is that it helps ESXi use the memory management technique of Transparent Page Sharing (TPS) more efficiently since there are chances that you are running a lot of duplicate pages spawned by these VMs in the physical memory of your ESXi servers. I have seen this reach 30 percent and can be fetched in a vCenter Operations Manager report if you have that installed in your virtual infrastructure.

With this I would close this article. I was hoping to give you a quick scoop in all these parts, but this article is now four pages. I hope this helps you make the right choices for your virtual infrastructure when it comes to vSphere Clusters.


This post originally appeared on Sunny Dua’s vXpress blog, where you can find follow-up posts 2 and 3. Sunny Dua is a Senior Technology Consultant for VMware’s Professional Services Organization, focused on India and SAARC countries.

What Did You Miss? Best Blog Posts for 2013

When you consider the constant flow of information we are submerged in on a daily basis, it’s no surprise that great insights occasionally escape our notice. As we reflect this week on the  last year, we thought we’d share a few of our most read and most shared posts from 2013—just in case you missed one. We hope they’ll help you step into 2014 with confidence, knowing you have these helpful tips in your back pocket (and that you can check back any time for new ones). Enjoy!


Four Commonly Missed and Easy to Implement Best Practices (Horizon View)
– By Nathan Smith, VMware EUC Consultant

It All Starts Here: Internal implementation of Horizon Workspace at VMware
– By Jim Zhang, VMWare Professional Services Consultant

4 Ways To Overcome Resistance to the Cloud
– By Brett Parlier, Solutions Architect, VMware Professional Services

Quickly Calculate Bandwidth Requirements with New vSphere ‘fling’
– By Sunny Dua, Senior Technology Consultant at VMware