The document discusses how Citrix and Microsoft provide a comprehensive desktop strategy through their joint solutions. It describes how their solutions enable businesses to centralize Windows-based applications, desktops, and servers in the datacenter and dynamically deliver them to users anywhere on any device. It also discusses how Citrix and Microsoft are working to build robust integrations between Microsoft System Center and Citrix XenApp and XenDesktop to realize the benefits of virtualization while leveraging existing investments.

1. 1

2. 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

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.
3

4. 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. 5

6. 6

7. 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. 8

9. 9

10. 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

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>
11

12. 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

13. “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

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

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

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

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

18. 18

19. 19

20. 20

21. 21

22. 22

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.
23

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.
24

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.
25

26. 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

27. 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

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.
28

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.
29

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.
30

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.
31

32. 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. 33

34. 34

35. 35

36. 36

37. 37

38. 38

39. The available desktop properties that XD(VDA) provides.
39

40. 40

41. 41

42. 42

43. 43

44. 44

45. 45

46. 46

47. 47

48. 48

49. 49

50. 50

51. 51

52. 52

53. 53

54. 54

55. 55

56. 56

57. 57

58. 58

59. 59

60. 60

61. 61

62. 62

63. 63

64. 64

65. 65