1

To meet the needs of a workforce which is ever more dynamic, global, and mobile, business need a comprehensive desktop strategy that address a range of key business requirements holistically . This includes:• End to end management of data and applications across physical and virtual assets• Security and Data protection for managed and unmanaged devices• Anywhere access for user’s data and applications, whether they local or mobile• Business Continuity for workforce agility and disaster recovery• And on‐demand access to applications, so users can self‐provision the applications they 

need in real time.

It’s no longer a world where IT simply provides users with PC’s loaded with locally installed applications.  Technologies have changed and business is changing with them, so IT’s desktop and application delivery strategy has to change as well.

<click>

Together, Microsoft and Citrix provide organizations with solutions that enable this comprehensive desktop strategy.

2

To meet the needs of a workforce which is ever more dynamic, global, and and mobile, business need a comprehensive desktop strategy that address a range of key business Partners for over 22 years, Citrix and Microsoft offer joint solutions that enable more than 230,000 businesses worldwide to reduce costs and increase IT flexibility and agility by centralizing Windows‐based applications, desktops and servers in the datacenter; dynamically delivering them to users anywhere, on any device. 

Our mutual goal is to combine our relative strengths to make OS, application, and user state virtualization easier to adopt, easier to deploy, and easier to manage.  

To meet this goal Citrix and Microsoft are working together to build robust integrations between Microsoft System Center and Citrix XenApp and XenDesktop, so that admins who are already familiar with System Center can realize the benefits of virtualization while leveraging their existing investment in tools, skills and IT processes.

3

To meet the needs of a workforce which is ever more dynamic, global, and and mobile, business need a comprehensive desktop strategy that address a range of key business Partners for over 22 years, Citrix and Microsoft offer joint solutions that enable more than 230,000 businesses worldwide to reduce costs and increase IT flexibility and agility by centralizing Windows‐based applications, desktops and servers in the datacenter; dynamically delivering them to users anywhere, on any device. 

Our mutual goal is to combine our relative strengths to make OS, application, and user state virtualization easier to adopt, easier to deploy, and easier to manage.  

To meet this goal Citrix and Microsoft are working together to build robust integrations between Microsoft System Center and Citrix XenApp and XenDesktop, so that admins who are already familiar with System Center can realize the benefits of virtualization while leveraging their existing investment in tools, skills and IT processes.

4

5

6

More so than any previous release of Configuration Manager, the 2012 release supports the model of user‐centric IT management.  

The new focus of SSCM is one of empowering users by putting them at the center of the IT universe:  It is about self‐service, its about users and their affinity with their personal devices, its about supporting a mobile workforce and the overall IT consumerization trend. 

This core principle of user‐centric IT has defined Citrix since we began as a company more than 20 years ago.

We are very excited about the power this user‐centric model provides and how that model is realized via integration of SCCM and XenApp.

<click>

7

8

9

So as an IT administrator the Connector provides a number of benefits for you

<click> First is unifies management under SCCM’s single pane of glass for your virtualized applications alongside side traditional MSI, App‐V, and CAB based applications.

<click> Second, it extends Configuration Manager’s reach so you can deliver any app to any user on any device.

<click> Third, it improves service level attainment by gracefully orchestrating updates for your XenApp farm, eliminating user downtime for OS and app deployments

<click> And Finally, it allows you to do all this while leveraging your existing investment in tools, skills, and IT processes.

<click>

10

As I mentioned earlier, 2012 is a very significant release of Configuration Manager.  

There are many new and valuable features…too many to go through here.  So today we’re going to focus on the three that are directly integrated with the the XA Connector in Project Thor:

<click>

‐ Deployment Types‐ User‐centric administration, and‐ The Application Catalog

The theme around these features is that they give administrators the ability to define policies that address this question:

<click>

11

As I mentioned earlier, 2012 is a very significant release of Configuration Manager.  

There are many new and valuable features…too many to go through here.  So today we’re going to focus on the three that are directly integrated with the the XA Connector in Project Thor:

<click>

‐ Deployment Types‐ User‐centric administration, and‐ The Application Catalog

The theme around these features is that they give administrators the ability to define policies that address this question:

<click>

12

“How do I the administrator deliver a particular to a particular user”

And not just how do I deliver it to them on their traditional desktop PC.  SCCM has been doing that for years.  What’s new is the ability for me to set rules to deliver that app differently depending on what device and location the user is accessing the application from.  

To show how this works, I’m going to turn it over to Prasanna who will explain and demonstrate user‐centric application delivery via the Connector in more depth.

Prasanna?

13

Let’s look a the first piece of what’s new.. Deployment Types. 

14

Let’s look a the first piece of what’s new.. Deployment Types. 

15

Let’s look a the first piece of what’s new.. Deployment Types. 

16

Let’s look a the first piece of what’s new.. Deployment Types. 

17

18

19

20

21

22

Let’s look at the end‐end workflow for deploying XenApp DT applications using Thor. Everything starts with the SCCM Admin. The admin’s intent is to deploy XA DT based apps to end‐users such as Tony. They go to through the 3 step deployment process that I explained on the previous slide. We have a Thor plugin to the SCCM console that adds the Citrix UI extensions to it.

Once the admin has configured the XA DT deployment parameters in the console, the Thor XenApp Agent service running on each of the XenApp workers works with the SCCM Agent to detect the pending deployment and in advance of a pending maintenance window, warns all logged on users of an impending reboot. It then starts to drain users off of the system and once inside a maintenance window and there are no users logged on to the XenApp Server, it then performs the actual deployment by talking to the SCCM Agent. If This entire orchestration process can be made to take advantage of Citrix PCM (Power and Capacity Management) server. PCM does this orchestration gracefully across the entire farm so that the entire server farm isn’t brought down all at once but inside the maintenance happens in a staggered fashion so that some servers in the farm are always up and running based on power and capacity management settings configured in PCM. This process is very similar to resurfacing a busy interstate highway. Instead of shutting down all lanes, maintenance is done on a lane by lane basis so traffic still keeps flowing, although a little slower.

23

Let’s look at the end‐end workflow for deploying XenApp DT applications using Thor. Everything starts with the SCCM Admin. The admin’s intent is to deploy XA DT based apps to end‐users such as Tony. They go to through the 3 step deployment process that I explained on the previous slide. We have a Thor plugin to the SCCM console that adds the Citrix UI extensions to it.

Once the admin has configured the XA DT deployment parameters in the console, the Thor XenApp Agent service running on each of the XenApp workers works with the SCCM Agent to detect the pending deployment and in advance of a pending maintenance window, warns all logged on users of an impending reboot. It then starts to drain users off of the system and once inside a maintenance window and there are no users logged on to the XenApp Server, it then performs the actual deployment by talking to the SCCM Agent. If This entire orchestration process can be made to take advantage of Citrix PCM (Power and Capacity Management) server. PCM does this orchestration gracefully across the entire farm so that the entire server farm isn’t brought down all at once but inside the maintenance happens in a staggered fashion so that some servers in the farm are always up and running based on power and capacity management settings configured in PCM. This process is very similar to resurfacing a busy interstate highway. Instead of shutting down all lanes, maintenance is done on a lane by lane basis so traffic still keeps flowing, although a little slower.

24

Let’s look at the end‐end workflow for deploying XenApp DT applications using Thor. Everything starts with the SCCM Admin. The admin’s intent is to deploy XA DT based apps to end‐users such as Tony. They go to through the 3 step deployment process that I explained on the previous slide. We have a Thor plugin to the SCCM console that adds the Citrix UI extensions to it.

Once the admin has configured the XA DT deployment parameters in the console, the Thor XenApp Agent service running on each of the XenApp workers works with the SCCM Agent to detect the pending deployment and in advance of a pending maintenance window, warns all logged on users of an impending reboot. It then starts to drain users off of the system and once inside a maintenance window and there are no users logged on to the XenApp Server, it then performs the actual deployment by talking to the SCCM Agent. If This entire orchestration process can be made to take advantage of Citrix PCM (Power and Capacity Management) server. PCM does this orchestration gracefully across the entire farm so that the entire server farm isn’t brought down all at once but inside the maintenance happens in a staggered fashion so that some servers in the farm are always up and running based on power and capacity management settings configured in PCM. This process is very similar to resurfacing a busy interstate highway. Instead of shutting down all lanes, maintenance is done on a lane by lane basis so traffic still keeps flowing, although a little slower.

25

Let’s look at the end‐end workflow for deploying XenApp DT applications using Thor. Everything starts with the SCCM Admin. The admin’s intent is to deploy XA DT based apps to end‐users such as Tony. They go to through the 3 step deployment process that I explained on the previous slide. We have a Thor plugin to the SCCM console that adds the Citrix UI extensions to it.

Once the admin has configured the XA DT deployment parameters in the console, the Thor XenApp Agent service running on each of the XenApp workers works with the SCCM Agent to detect the pending deployment and in advance of a pending maintenance window, warns all logged on users of an impending reboot. It then starts to drain users off of the system and once inside a maintenance window and there are no users logged on to the XenApp Server, it then performs the actual deployment by talking to the SCCM Agent. If This entire orchestration process can be made to take advantage of Citrix PCM (Power and Capacity Management) server. PCM does this orchestration gracefully across the entire farm so that the entire server farm isn’t brought down all at once but inside the maintenance happens in a staggered fashion so that some servers in the farm are always up and running based on power and capacity management settings configured in PCM. This process is very similar to resurfacing a busy interstate highway. Instead of shutting down all lanes, maintenance is done on a lane by lane basis so traffic still keeps flowing, although a little slower.

26

As and once the apps have been deployed to the XenApp servers in this fashion that I just described, the Connector service starts to publish those applications to users. Publishing creates an association between the app, the users in the deployment and the XenApp servers that it was just published to. Once the app has been published, it is available to be accessed by end‐users – either via Citrix Receiver or via the SCCM Application Catalog or deployed as a mandatory app to the user’s desktop the next time they login.

The actual process of deploying the app to the user’s desktop via Receiver is simple. The Thor XenApp Deployment Type Handler serves as a conduit b/w the SCCM client and Receiver. When the user goes to the SCCM Catalog and installs the application or when the SCCM Agent pushes the application as a mandatory app, the XA DT handler is invoked by SCCM which in turns works with Citrix Receiver to make the subscription on behalf of the user. The app seamlessly shows up on the user’s start menu. Of course, clicking on it uses Citrix Receiver and Citrix’s HDX technology to launch the application

27

What we have seen so far is how Thor works end‐end in an environment consisting of physical XenApp servers. Now lets look at how it operates in a Citrix PVS environment consisting of single base image or master image that the XenApp worker clones boot off of.

The first step for the admin is to use the SCCM console to target the relevant apps and updates to the PVS master image. Once the new image is marked as “Production” in the image library, in advance of maintenance windows, clone XenApp workers go through the same graceful orchestration process, that I described in the previous example. This is enabled by the Citrix Thor Agent working hand‐in‐hand with the PVS Agent and the Citrix PCM server. The Thor XenApp Agent reboots the XA clone workers once users have been drained and within a maintenance window. On reboot, they stream the new master vDisk image that contains the updated image with the new apps and updates. Now although the clones are running the new image with the new apps, it doesn’t show up in Receiver yet. The missing piece of the puzzle is the Connector task. Once the SCCM Agents have reported back to the SCCM database that the apps have been successfully deployed, the Connector service publishes the application to the XA controller database making the association between the app, the user and the servers that it was deployed to. Now its available to end users via Receiver. 

28

What we have seen so far is how Thor works end‐end in an environment consisting of physical XenApp servers. Now lets look at how it operates in a Citrix PVS environment consisting of single base image or master image that the XenApp worker clones boot off of.

The first step for the admin is to use the SCCM console to target the relevant apps and updates to the PVS master image. Once the new image is marked as “Production” in the image library, in advance of maintenance windows, clone XenApp workers go through the same graceful orchestration process, that I described in the previous example. This is enabled by the Citrix Thor Agent working hand‐in‐hand with the PVS Agent and the Citrix PCM server. The Thor XenApp Agent reboots the XA clone workers once users have been drained and within a maintenance window. On reboot, they stream the new master vDisk image that contains the updated image with the new apps and updates. Now although the clones are running the new image with the new apps, it doesn’t show up in Receiver yet. The missing piece of the puzzle is the Connector task. Once the SCCM Agents have reported back to the SCCM database that the apps have been successfully deployed, the Connector service publishes the application to the XA controller database making the association between the app, the user and the servers that it was deployed to. Now its available to end users via Receiver. 

29

What we have seen so far is how Thor works end‐end in an environment consisting of physical XenApp servers. Now lets look at how it operates in a Citrix PVS environment consisting of single base image or master image that the XenApp worker clones boot off of.

The first step for the admin is to use the SCCM console to target the relevant apps and updates to the PVS master image. Once the new image is marked as “Production” in the image library, in advance of maintenance windows, clone XenApp workers go through the same graceful orchestration process, that I described in the previous example. This is enabled by the Citrix Thor Agent working hand‐in‐hand with the PVS Agent and the Citrix PCM server. The Thor XenApp Agent reboots the XA clone workers once users have been drained and within a maintenance window. On reboot, they stream the new master vDisk image that contains the updated image with the new apps and updates. Now although the clones are running the new image with the new apps, it doesn’t show up in Receiver yet. The missing piece of the puzzle is the Connector task. Once the SCCM Agents have reported back to the SCCM database that the apps have been successfully deployed, the Connector service publishes the application to the XA controller database making the association between the app, the user and the servers that it was deployed to. Now its available to end users via Receiver. 

30

What we have seen so far is how Thor works end‐end in an environment consisting of physical XenApp servers. Now lets look at how it operates in a Citrix PVS environment consisting of single base image or master image that the XenApp worker clones boot off of.

The first step for the admin is to use the SCCM console to target the relevant apps and updates to the PVS master image. Once the new image is marked as “Production” in the image library, in advance of maintenance windows, clone XenApp workers go through the same graceful orchestration process, that I described in the previous example. This is enabled by the Citrix Thor Agent working hand‐in‐hand with the PVS Agent and the Citrix PCM server. The Thor XenApp Agent reboots the XA clone workers once users have been drained and within a maintenance window. On reboot, they stream the new master vDisk image that contains the updated image with the new apps and updates. Now although the clones are running the new image with the new apps, it doesn’t show up in Receiver yet. The missing piece of the puzzle is the Connector task. Once the SCCM Agents have reported back to the SCCM database that the apps have been successfully deployed, the Connector service publishes the application to the XA controller database making the association between the app, the user and the servers that it was deployed to. Now its available to end users via Receiver. 

31

What we have seen so far is how Thor works end‐end in an environment consisting of physical XenApp servers. Now lets look at how it operates in a Citrix PVS environment consisting of single base image or master image that the XenApp worker clones boot off of.

The first step for the admin is to use the SCCM console to target the relevant apps and updates to the PVS master image. Once the new image is marked as “Production” in the image library, in advance of maintenance windows, clone XenApp workers go through the same graceful orchestration process, that I described in the previous example. This is enabled by the Citrix Thor Agent working hand‐in‐hand with the PVS Agent and the Citrix PCM server. The Thor XenApp Agent reboots the XA clone workers once users have been drained and within a maintenance window. On reboot, they stream the new master vDisk image that contains the updated image with the new apps and updates. Now although the clones are running the new image with the new apps, it doesn’t show up in Receiver yet. The missing piece of the puzzle is the Connector task. Once the SCCM Agents have reported back to the SCCM database that the apps have been successfully deployed, the Connector service publishes the application to the XA controller database making the association between the app, the user and the servers that it was deployed to. Now its available to end users via Receiver. 

32

33

34

35

36

37

38

The available desktop properties that XD(VDA) provides.

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65