Archive

Archive for December, 2010

Forefront Identity Manager 2010: Best Identity and Access Management Product

December 30, 2010 Leave a comment

Forefront Identity Manager 2010

 

Just a quick and short post about Forefront Identity Manager. Anyway, it’s really nice to see that Forefront Identity Manager 2010 (ex. Identity Lifecycle Manager) won the gold award by Information Security Magazine in identity and access management category.

Quote:

Despite a large field of battle-tested competitors, Microsoft’s legacy identity product narrowly surpassed IBM for our No.1 ranking. Identity Lifecycle Manager 2007, which was replaced in March by Forefront Identity Manager 2010, features identity synchronization, user provisioning, and management of certificates and smartcards; it requires Windows Server 2003 or 2008 and SQL Server. Readers gave it solid marks across the board, particularly for ease of use, integration with associated products and comprehensive and flexible reports.

 

Cheers to Forefront Identity Manager!

What is Private Cloud a.k.a Private Cloud for beginners

December 21, 2010 Leave a comment

What is private cloud

These days you can find tons of information on Internet regarding Private Cloud. What is it, how it can be used, how can you benefit from it – all those scenarios and hundreds more are explained everywhere. My intention is not to detaily describe Private Cloud or Cloud Computing. My intention is to describe private cloud as easy as it gets, preferably with „real“ world comparison. Also, keep in mind that there are a few Private Cloud „offerings“, and that herby I’m talking about IAAS – Infrastructure as a Service.

Ok first what does that (IAAS) mean? Let’s analyze those two words; infrastructure and service. In IT world infrastructure is actually combination of following resources: memory, CPU, storage, networking,operating system etc.. Ok now we have also a service which can be defined as „ providing something to someone“. So it’s clear that IAAS is actually  a model where someone provides infrastructure services to someone else. Keyword here is someone, because if this someone is public company providing services to some other company – then this can be „normal Public Cloud“. On the other hand if for example one company provides infrastructure as a service to departments in that same company – then that can be called „Private Cloud“.

If we compare that to some plastic real world example it could be something like Rent a Car model. Smiješak So, in the world there are a lot of Rent a Car companies in which you decide to go if you’d like some services [a Car]. You also decide that this particular car needs to have some amount of horse power, CCM, needs to have 4WD etc. Then you pay for all that and you get that car as a service, exactly as you wanted, and fast too. That could be compared to Public Cloud because some public company „host“ services (e.g. car) for you or your company. On the other hand, your company can have maybe dozen cars available for you and for other employees to use. You then explain  why you need a car, when you need it and what kind of car you need. Your company provides you with that car so in that case you’d also get car as a service, but now this service is private.

Ok, now after that comparison, let’s see how can that Private IAAS Cloud be achieved in IT world. Of course, here virtualization (among other stuff) comes in place. Why? Well because of some main characteristics of cloud (whether public or private) :

  • Scalability
  • Automatism
  • Elasticity

In other words, when you or your department need Windows Server 2008 R2 with 4 GB of RAM, 2 CPU’s, 100 GB disk and Active Directory Services role installed, you need that fast and without much intervention (you don’t want to configure everything by yourself). In other other words, if you’d need that same Windows Server 2008 R2, and if it can only be served to you in a physical manner (a.k.a real metal physical server), you would  probably not get it in that same automatic, fast and „elastic“ way.

So yeah, that’s about it in high level and without mentioning actual technologies used for building private cloud solution. My way of demystified Private Cloud and IAAS.

 

P.S. In some of my future post I will cover actual Microsoft Private Cloud Offerings and technologies included – so stay tuned.

Application Virtualization (App-V) – Use Case Scenarios

December 12, 2010 Leave a comment

When, where and how to use Microsoft Application Virtualization

Scenarios of using Application Virtualization

Virtualization of applications in recent years is slowly but surely being used more and more often, but still  I can not say that it is generally accepted technology such as server virtualization. The first step towards a general acceptance of application virtualization is certainly a  good awareness of  possible implementation scenarios and the various benefits that technology brings.

 

 

What is application virtualization?
Virtual applicationMicrosoft Application Virtualization (App-V) is one of application virtualization solutions on which you probably ran into somewhere.  However, it is better to briefly summarize the theoretical aspects so that the usability of technology can also be clarified. So, application virtualization brings a new approach to interaction of applications and operating system. Namely, with standard approach we are aware that we first need to install application on OS to make it work. Also we know that applications are closely related to the operating system on which they are installed (e.g. a lot of registry entries, dll files etc…). If you ignore all those standard application lifecycle behavior  (installation, maintenance, uninstall), then you’d get a lot more dynamic applications and more manageable applications. In simple words, when using App-V Solution applications are turning into services that are available on request. Most applications today can be converted into virtual which brings many new application scenarios.

No more installation!
No installationNot so long ago to install some applications we needed to bring a dozen diskettes and bunch of patience. And then (as we are lucky bastards) on tenth diskette we run into some kind of a read error. That was frustrating in many ways!  Through the years the process has changed in the sense that we do not need so many floppy disks, but still applications "require" to be installed by following specific installation procedure. With App-V, application installation process is gone. Once created, the virtual application package is placed on the central server and deployed to users on request. There are of course many other systems for application deployment (SCCM…), but what with applications that do not have the installation procedure? They can also be packaged using App-V solution. Examples are in-house developed applications that do not have a standard installation procedure, but they must be installed and configured separately and manually on each computer.  For example if you configure application settings (e.g. strings to database, view settings and many others) during packaging phase (App-v Sequencing) those settings will be applied on every application when distributed to clients.

 

Simple application upgrade

Application upgradeOnce installed applications eventually need to be upgraded,  and that can be a tedious job because of computer restarts, errors etc… Virtual applications behave differently. Namely, when applications are placed on a central server, you need to make just one virtual package update on the server and all applications on clients will be upgraded to the latest version or patch. In addition, users will experience no interruption in work. Users can use application at the same time when system administrator wants to set a new upgrade. The next time the user runs the same application it will be upgraded (no restart, no interruptions, no errors, no update procedure). Ok, let’s  briefly switch to the central App-V Server and its relationship with the client computers. Unlike the standard push principle deployment of applications (with SCCM or other ESD solutions), App-V Server uses the pull approach where client computers literally pull a package by package (using SMB, HTTP, or RTSP protocol) until the virtual application is successfully  running. After that entire application is cached on client side (if so configured)  you no longer need a connection to server. That is one of many misunderstandings when it comes to virtual applications. Namely, a lot of users thinks that they need to be constantly connected to central App-V server (Application Virtualization Management Server).

Portable virtual applications
Portable applicationsOn the other hand, if there are no possibilities of using App-V server, applications can be deployed simply using  shared folder on a server or using portable USB drive. One of the characteristics of virtual application here imposes itself – portability of applications. We can say that the virtual application can be transferred from one computer to another using just USB. Of course APP-V client is required on computer for those virtual applications. Without App-V client installed on computer you can not run any App-V virtual applications.

Isolation (Sandbox), virtual plugins… 
Hy there I'm isolated virtual appIn the previous section, I have often mentioned the installation process, which was eliminated in virtual applications. On this characteristic is based on one of the biggest advantages of virtual applications. Specifically, each virtual application is running in so-called isolated environment – Sandbox. When running in sandbox, virtual applications are not in conflict. Today is not uncommon on a single computer that at the same time there are hundred applications, which often causes conflict between them. In such scenarios, there are two possible solutions; simply stop using the conflicting application or implementation of App-V solution. Certainly the latter case is better solution because it does not require much investment in new infrastructure and you  can keep all applications. In addition, it is possible to use application virtualization in scenarios when  having multiple versions of the same application, which is a common need in cases of testing or adaptation of new versions. For example, you can simultaneously on one computer run Office 2007 and Office 2010 (or other combinations).
On the other hand it is possible to integrate"normally" installed applications with virtual plugins. Wondering what is the benefit of this scenario?  Take for example a company with 100 employees who on a daily basis run web applications that use Java version 6, and on the other hand couple of users or departments use applications that do not work normally with specified version of Java.  In this case there is a problem because  upon installing Java update a previous version of Java is replaced and some older web applications does not work.  With the help of App-V solution on the same computer different versions of Java (or any other plugin) can be used simultaneously. Clearly, in this case, these plugins are virtualized.. The same goes for any other applications and plug-ins.
When mentioning conflict of applications, then  probably most affected are terminal servers. Specifically, on terminal server there are bunch of applications which users run using Remote desktop protocol. So all applications are actually executed on terminal server while users only see presentation layer of application. As servers are now quite powerful, it is clear that Terminal Server can run hundreds of application simultaneously. But that is often not the case because a  lot of applications are in conflict. In those scenarios companies implement so called Terminal Server Farms. By doing that, a lot of servers are underutilized and that’s exactly what we want to avoid by using virtualization.  App-V can save the day in that case. Specifically when using App-V on Terminal Server, you can run as many applications as you want, because they are not in conflict – they are in sandbox. So if applications can run on terminal server, they can be served to users using TS (RDS) Remote App etc.

64 bits, VDI, shared cache …
Banner_vApp-V solution tightly integrates with Active Directory so that the applications are only delivered to those users that are entitled to use applications. So administrator defines security group in Active Directory and defines users which should receive the application on their desktop. Once the user logs on to a computer (with domain user and pass),he will see all virtual applications instantly. But keep in mind that virtual applications are not tied to computer meaning that user will see his applications on every computer on which he log on (Roaming).  This scenario is particularly suited for call centers and in general for situations where employees do not use the same computer every day. Scenario can be further extended to remote users, who can use the application wherever they are.
Tight integration of App-V solution with Active Directory has a beneficial effect on the OS deployment process, and generally process of  creating the OS image. By default, companies are creating fat OS images with a lot of preinstalled applications so that every department is covered with all applications. This increases the size of the OS image, and users often have applications which they do not use. On the other hand, if using App-V, OS image can be “clean” with maybe just a few preinstalled applications, while other users receive virtual applications as soon as they firs log on to domain.
Deployment of the new OS is particularly interesting topic at a time when most people still use Windows XP and have  good intention to switch to Windows 7. Since version App-V 4.5 SP1 virtual applications are officially supported on Windows 7. In addition, this year version 4.6 was released with  support for 64 bit platform. The new version also comes with  a little-known possibility of shared cache , which is particularly useful in Virtual Desktop Infrastructure (VDI) solutions. In VDI solutions virtual machines are located in data centers and users access them from their computer, or using thin clients. Of course, users will access these virtual machines to use certain applications. If those applications are installed separately on each virtual machine, then the capacity of these virtual machines occupy a fairly large amount of storage. Take for example that the average virtual machine user have about 20 applications with a total capacity of 10 GB. For 100 users,in this case it is necessary to book 1000 GB of disk space only for applications. Using App-V shared cache all applications doesn’t have to be placed in each virtual machine individually. Instead applications can be placed on shared storage. So all virtual machines will use the same shared cache of virtual applications (10GB), meaning that you could potentially save 90% or more of storage space.

Finally, it is easy to conclude that with the use of virtual applications many new application scenarios appear and virtual applications bring many benefits. According to research, the use of virtual applications significantly reduces the time required for deployment, reducing the number of help desk calls and generally reducing the costs associated with maintaining applications. But of course, with each technology and therefore with App-V there are some risks and limitations. Some applications can not be virtualized, some do not behave well in a virtual environment, but for all other applications I must say that it is really very beneficial to use App-V and by doing that take one step closer to real dynamic desktop.