Announcement

Collapse
No announcement yet.

VMWare, SCCM, Hyper V and APP-V

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • VMWare, SCCM, Hyper V and APP-V

    Hi

    I am trying to understand a few points regarding virtualisation of applications and various client / server OS and would be greatful if someone could clarify the following

    1. Is virtualising applications in VMWare the same as virtualising applications using SCCM, Hyper V and APP-V? Or do you need to use a combination of the different software to virtualise apps? Can all be done in one piece of software?

    3. Where does WDS fit into virtualising applications and deploying OS?

    3. How does SCCM and App-V work with regard to virtualising apps?

    Thank you any advice on the above would be much appreciated. I just want someone to help simplify how the whole virtualisation works with the various tools and software out there. How it all fits together if you like

    Thanks
    Bongo

  • #2
    Re: VMWare, SCCM, Hyper V and APP-V

    It often comes down to customer requirements and what they aready have.


    1. VMware have ThinApp for application virtualisaton. Citrix have XenApp and Microsoft have AppV. Microsoft SCCM with regards to application rollout can be used to roll out Virtual applications such as AppV packages but is not a virtual application environment, it is a way of rolling out software to users and computers, which results in the application being locally installed.


    With regards to application virtualisation, you would tend to use a sequencing tool, which creates the virtual application package. It then runs in its own bubble and generally you would stream it from a central server. However, you generally have the ability for them to be cached locally as well. You would often look for application recipes, which are methods people have used to virtualise an application.


    Personally, I have worked a lot with AppV. Application wise, if an application ends up not being supported by AppV, we will see if it is supported using Microsoft's Remote App. If not supported there, we would then use SCCM to roll it out.


    Hyper-V is a Hypervisor and used for Virtual Machines. It's nothing to do with applications.


    2. WDS is more for rolling out an OS to a physical PC and there are a few methods. It's nothing to with application virtualisation. If a requirement and configured correctly, you can roll out an OS to a Virtual Machine as well though you would tend to use templates or if you have a VDI environment, something suchas Citrix or Quest vWorkspace. I don't use WDS in our VDI and virtualisation solutions.


    3. AppV can be configured in a number of ways. We tend to use AppV only for streaming virtualised applications to the end user. However, when you sequence the application, an MSI can also be created. We could then take that MSI and use SCCM to distribute the virtualised application to the appropriate devices and users. AppV can only deploy applications to the user. SCCM can do computers and users. The MSI only provides the details of where to go to pull the application from. We tend to use http for that mechanism and have IIS point to the virtualised package location. However, we sometimes use UNC path as well. DFS replication is used to provide package redundancy.


    You are best to start to review these solutions usin Technet and Technet Edge.

    Comment


    • #3
      Re: VMWare, SCCM, Hyper V and APP-V

      Hi

      Thanks for the excellent detailed reply.

      Just wanted to clarify a few points if possible


      1. "SCCM is a way of rolling out software to users and computers, which results in the application being locally installed."

      I understood applications to be stored centrally on some APP-V or SCCM server rather than locally on a users PC? As users often hot desk and move around. Where does the Q drive fit into all this?


      "However, you generally have the ability for them to be cached locally as well"

      Please can you clarify what you mean by having virtual apps cached locally as well?


      "Personally, I have worked a lot with AppV. Application wise, if an application ends up not being supported by AppV"

      From what I understand SCCM is commonly used now days as it supports most apps. Any reason why specific apps are not supported with APP-V? Is it to do with drivers?

      3. "We tend to use http for that mechanism and have IIS point to the virtualised package location. However, we sometimes use UNC path as well. DFS replication is used to provide package redundancy"

      How does IIS fit into this process? Also how do you use DFS to provide package redundancy in the same process?

      Any further help would be greatly appreciated

      Thanks
      Bongo

      Comment


      • #4
        Re: VMWare, SCCM, Hyper V and APP-V

        1. SCCM and AppV have packages that are used as the source files of an application. SCCM if not used to roll out an Appv packages, will leave the application installed locally. If used to roll out AppV packages, it's just a way of indicating to the user, who has been granted access to the Appv application, where to download it from. Whether youuse SCCM or the Appv Client, it will stream the Appv application to the local PC. The first user who does that for an Appv application effectively creates a cached copy of that Appv application on the C drive. This cache is shared between users who have been granted access to the Appv application and if configured appropriately (Appv Client/SCCM settings), the application can be used from the cached copy as oppose to having a connection to the location of the Appv source files. The Appv application has to stream down locally prior to it being opened. This applies to file associations and shortcut icons as well.


        Q drive is the default drive for the Appv Client. When you sequence an application for Appv, best practice is to use the Q drive as the installation directory as oppose to C drive\Program Files. However, you can still install to C drive is an application is insupported. All program files are them moved to the Q drive from C drive by the Appv sequencing tool.


        The Appv Client gives you the Q drive on the end user computer and is the drive letter used when running Appv applications. You will not be able to browse the Q drive via Windows. You can from within an application or by running CMD within the CMD bubble when you first launch it be editing the OSD file.


        SCCM is still used to roll out applications. However, it does not install virtual applications. It's just another method to install applications to save you having to build another image with the application installed, and roll that out with something such as WDS or you manually installing it yourself.


        As you mention, drivers are unsupported. Appv recipes give you an idea of some unspported applications or limitations. Others, it's trial and error an you can use something like ProcMon when troubleshooting, which is why we still use Appv, Remote App and SCCM. If a customer doesn't have SCCM, Group Policy could be used or its just a case of ensuring they are locally installed on the image you roll out.


        Some I locally install are Microsoft Office, due to limitations with SharePoint if you Appv it, Plug-Ins, anything that needs a driver and so on. There are many more.


        3. IIS is used as a streaming server. A mechanism that the Appv Client connects to, to stream the Appv application to the local cache. DFS replication is used to provide Appv package redundancy. The packages that are used to stream the application to the end user for th streaming server. If you have more than 1 Appv server, DFS is used to replicate the package files between both of them. The Appv Client points to a Hardware NLB that in turn, will connect to one of the Appv servers that have the same packages.


        The OSD file can use a number of protocols for the streaming, UNC, http, https, rtsp or rtsps. Due to doing Appv deployments for hundreds of applications, we tend to use http providing the VDI solution is based in 1 physical location. However, if they have a number of physical sites with WAN links, we will use the DFS Domain Based namespace created for the Appv package location as the UNC path for streaming, so wouldn't then use http. Furthermore, we would add the Appv servers based at the remote sites to DFS replication.

        Hope that makes sense.

        Comment

        Working...
        X