Kraft & Kennedy, Inc. provides technology and strategic consulting services to law firms, corporate legal departments and financial services firms. We can help you analyze, plan, implement and manage business and technology solutions to optimize your organization's functionality and processes.
For years organizations have relied on tape drives and changers for backup and recovery of their critical data. Despite many predictions to the contrary, tape is still alive as we begin 2010.
When virtualization became popular it presented a challenge to those looking to continue to use their tape drives in fully virtualized environments. If you were using VMware you could use SCSI pass-through to present a tape drive or changer directly to a virtual machine but that prevented you from using any advanced features like VMotion. It also tied your tape drive and VM to a single host containing a SCSI card, making things complicated if that host were to experience a hardware failure.
Before creating an image of a XenApp server, several steps must be performed to generalize the XenApp installation, in order to remove the machine-specific information from the install and allow the server to come online and join the XenApp farm as a unique entity. In the past, this was either accomplished manually or through the use of a set of scripts. Citrix has since released a small MSI that contains a command-line tool and a Windows service that can be leveraged to quickly generalize a XenApp installation. The tool is called XenAppPrep and it can basically be thought of as the equivalent of sysprep for Windows, only used with XenApp installations.
With XenAppPrep, you can easily prepare and clone your XenApp servers, either by traditional Ghost/image type methods or through the use of Provisioning Services (talked about in my previous post Citrix Provisioning Services Part 2 – PVS with XenApp!). Using XenAppPrep is a simple process:
As mentioned in my previous blog post about the Exchange 2010 RPC Client Access Service and the ClientAccessArray, Exchange’s dependence on the Client Access Server (CAS) role has increased dramatically in Exchange 2010. This is because, in Exchange 2010, on-network Outlook MAPI connectivity now connects to a mailbox through the CAS role via the RPC Client Access Service. As a result, high availability of the CAS role is crucial since any failure of CAS could affect Outlook client connectivity. For smaller implementations or those where the limitations of native Windows Network Load Balancing (NLB) are not a major problem (please see my previous blog post for more information), NLB can work well. The process for configuring NLB is fairly straightforward and I’ve outlined the steps below.
For years the best practice has been to disable screensavers on virtual machines. Screensavers take memory and CPU cycles to run and that can hurt consolidation ratios, especially when there is no reason to run a screensaver on a server VM. After all, why run a screensaver on a server that doesn’t actually connect to a monitor? Seems obvious and almost unnecessary to bring up in 2009.
While working on a recent VDI project, I noticed unexpectedly high CPU utilization on a seemingly idle virtual desktop. Turns out that the desktop image we were given had the 3D Flying Objects screensaver enabled. When it kicked in after the desktop went idle it started taking a fair amount of the CPU. How much CPU it was using might surprise you. Take a look:
Microsoft has just announced that Exchange 2010 is now globally available! Please read more information at the MS Exchange Team blog at http://msexchangeteam.com/archive/2009/11/09/453096.aspx.
Exchange 2010 binaries are now available for download.
My last post Citrix Provisioning Services Part 1 – What Is It? served an introduction to what exactly Citrix Provisioning Services is capable of. Below I hope to open people’s eyes to using PVS for something other than VDI, as it is often thought of as a part of the XenDesktop suite. However PVS is actually independent of XD or VDI, and can be utilized in combination with XenApp to bring single-image benefits to the Terminal Services world.
Provisioning Services allows for server consistency, easier maintenance, dynamic servers, and aids in disaster recovery.
Creating a XenApp environment that is more dynamic and easier to maintain is a goal for many XenApp administrators. The addition of Provisioning Services to a XenApp implementation can go a long way to achieving those goals. By leveraging the single-image management capabilities of PVS, administrators can dramatically reduce the costs involved with deploying and maintaining their XenApp farms. While at the same time, guaranteeing consistency between and ensuring peak performance of each server in the farm. All while being capable of quickly adapting to changes in load and disaster scenarios.
Microsoft has announced that Exchange 2010 has been released to manufacturing with expected general availability and launch to be announced at TechEd Europe 2009 in early November. More information on Microsoft’s official announcement of Exchange 2010 can be found at the MS Exchange Team blog here. Exchange 2010 marks a significant milestone in the development of Exchange Server. Some of the most important features have been summarized below but many more exist that make this a compelling upgrade for all firms.
Please note that Exchange 2007 SP2 and/or Exchange 2003 SP2 are required for coexistence with Exchange 2010 in the same Active Directory site.
Please refer to my three-part blog post series on Exchange 2010’s specific benefits for law firms (Part 1 can be found at http://blogs.kraftkennedy.com/index.php/2009/08/19/exchange-2010-benefits-for-law-firms-part-1-of-3/). Check back often for additional blog posts about the new features of Exchange 2010.
One of the great features of desktop virtualization (VDI) being touted by the industry is the ability to manage and update all of your desktops from a single central master image.
Citrix’s solution to the single image process is accomplished by a product called Provisioning Services (PVS). This software is the result of their purchase of a company called Ardence back in 2007. Provisioning Services is an often misunderstood piece of software, and its great benefits and potential are not necessarily apparent to everyone.
PVS works by streaming a master (read-only) image from the server to a target server or workstation. Any subsequent writes are then sent back to the PVS server and written to a cache file. The reads and writes are sent back and forth between the PVS server and target in a constant stream over the network. The easiest way to grasp this is to imagine that the cable connecting the hard disk inside of the server to the motherboard (and thus the CPU and RAM) is replaced by a network cable running back to the PVS server. The operating system sees the PVS disk as though it were a normal hard disk, and everything is done entirely transparent to the OS. The magic happens when the server is powered up; instead of booting from a local disk it is instead set to boot to the network card (PXE, BOOTP) which talks to a service on the PVS server, which streams the assigned operating system image to the target. The target device starts up immediately, as though it was booting from a local disk.
The beauty here is that this single read-only image can be simultaneously streamed to multiple diskless targets, both physical and virtual. This central image can now be maintained in one place. This makes tasks such as installing updates or new software quick and easy. After installing an update into the master image, all machines running that image will boot up into the updated image on next restart. To put that in perspective, think of the time and effort required to push out something such as a service pack to Windows or Microsoft Office to your entire firm. Now imagine simply installing that update once and having every machine in your environment receive that update on next reboot, without any additional effort.
Look for a follow-up post discussing the benefits that Provisioning Services can bring to a XenApp implementation.
High availability and site resiliency have evolved a great deal from early versions of Exchange through Exchange 2007. While Exchange 2007 introduced the concepts of Single Copy Clustering (SCC) and Cluster Continuous Replication (CCR) for high availability and Standby Continuous Replication (SCR) for site resiliency, each had very specific benefits and drawbacks. CCR gradually became Microsoft’s and the industry’s preferred solution for high availability because of its robust availability capabilities but concerns about manageability, scalability, and associated storage cost were all factors when settling on a design. SCR extended CCR technology to provide a robust and cost effective solution for site resiliency but many firms were frustrated by the configuration and database activation processes and that all administration must be completed via cmdlets.
Continue reading…
With Server Based Computing and consolidation becoming increasing prevalent along with the enormous buzz of VDI, I think it is worth debunking some of common myths of XenApp and Terminal Server. Below are the most common misconceptions that I continue to hear from IT folks today on the limitations of XenApp/Terminal servers that I have debunked from real world experience supporting and working with different terminal server environments.
Myth 1: Application compatibility is a huge problem on Terminal Servers.
There might have been some truth to this myth a decade ago, but in reality this is just not a big problem in the 2003/2008 world. From my first hand experience, I can say that an application that works on XP will work on 2003, what works on Vista, will work on 2008, etc. Are there some exceptions? Of course. However, these applications are few and far between, yet the “application compatibility” myth continues to circulate. This myth was probably true in the NT/2000 OS where applications did not do a good job of differentiating between “user” and “computer” parts of an installation. Since Windows XP, application developers have done a better job writing “user” specific information in the user profile and “machine” specific information in Program Files, or HKLM. I would probably attributed to the “Fast User Switching” feature introduced in XP. Whatever the reason, this is just not a problem anymore.