SYN224: Best practices for migrating from Web Interface to StoreFront Services

5,340 views
5,052 views

Published on

While StoreFront Services goes beyond Web Interface in many areas, it does not support all features of Web interface. Determining when and how to migrate to StoreFront Services is a challenge faced by many Citrix administrators. Hear from the product experts, who will share migration considerations and best practices and considerations. This session will also cover upcoming StoreFront Services capabilities in future product releases.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,340
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
234
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

SYN224: Best practices for migrating from Web Interface to StoreFront Services

  1. 1. © 2014 Citrix. Confidential.1
  2. 2. © 2014 Citrix. Confidential.2
  3. 3. © 2014 Citrix. Confidential.3 •  15  years  ago  .   •  Work  horse  for  enabling  web  access  and  been  customiza;on     •  Non  layered  code  base,  hard  to  maintain,  upda;ng  from  version  to  version  is  difficult,  and  we  found   about  two  years  ago  that  it  had  become  too  difficult  to  add  new  func;onality.     •  These  factors  coupled  support  for  J-­‐Sharp  ending  launch  of  StoreFront  two  years  ago.   •  Extended  support  un;l  August  2016  to  give  you  ore  ;me  to  Migrate      
  4. 4. © 2014 Citrix. Confidential.4 •  Even More reasons to migrate….. •  Pass-Through Authentication in Citrix Receiver for Web •  Hiding Applications in Citrix StoreFront •  Provisioning All Applications to All Users in Receiver for Web •  Multiple Launch Prevention in Citrix Receiver for Web •  Parallel Resource Enumeration in StoreFront •  Store Customization SDK •  Customizing-receiver-for-web-2-5
  5. 5. © 2014 Citrix. Confidential.5 •  We  going  to  cover  these  topics  
  6. 6. © 2014 Citrix. Confidential.6 •  What  informa;on  is  needed  to  migrate?   •  Most  of  the  informa;on  here  should  be  familiar  for  any  WI  administrator.   •  For  NetScaler  gateway  single  sign  on,  an  internally  (LAN)  reachable  address  on  the  gateway  is  needed.   This  is  oRen  the  ‘SNIP  –subnet  IP’  address.   •  See  hWp://support.citrix.com/proddocs/topic/dws-­‐storefront-­‐25/dws-­‐plan-­‐account-­‐discovery.html  for   informa;on  on  seZng  up  email  based  discovery  for  Receivers.  
  7. 7. © 2014 Citrix. Confidential.7 •  WI  and  PNA  used  a  proscrip;ve  model  where  all  applica;ons  were  put  in  front  of  the  user   •  Storefront  &  Receiver  have  self  service  built  in  allowing  the  user  to  control  what  set  of  applica;ons  are   needed  for  their  role.   •  Users  don’t  have  to  do  all  of  the  work  themselves  as  Storefront  and  Receiver  support  applica;ons   being  automa;cally  subcribed  by  the  admin  applying  configura;on.   •  With  Storefront  2.5  that  seZng  can  be  applied  to  the  whole  Store.  The  hope  is  that  the  best  of  both   models  is  available  to  suit  all  use  cases.  
  8. 8. © 2014 Citrix. Confidential.8 We  are  oRen  asked  how  best  to  migrate  users  to  SF.  Best  prac;ces  is  to  migrate  users  in  phases.   •  Test   •  Members  of  the  IT  team  test  the  func;onality  of  the  environment  when  accessed  by  means  of  the  new  Receiver  version.     •  Pilot   •  A  selected  group  of  users  will  use  the  new  Receiver  to  connect  to  XenApp  on  a  daily  basis.   •  Produc;on   •  The  new  Receiver  is  rolled  out  to  the  remaining  users  gradually.  
  9. 9. © 2014 Citrix. Confidential.9 •  Turn over to Simon to cover what you’ll need to know to deploy StoreFront in your environment  
  10. 10. © 2014 Citrix. Confidential.10 •  Key  difference  in  architecture  for  Storefront  from  WI  is  that  the  web  UX  component  is  fully  separated.   RfW  is  a  javascript  applica;on  that  runs  in  the  users  browser  and  uses  the  web  services  of  Storefront  in   much  the  same  way  as  a  na;ve  Receiver  
  11. 11. © 2014 Citrix. Confidential.11 There  are  three  main  deployment  modes  of  Storefront:   The  simplest  is  where  you  don’t  really  see  Storefront  as  a  separate  component  as  it  is  deployed  ‘on  board’  with   the  XenDesktop  DDC.  There  it  is  largely  managed  by  XD  Studio.   The  next  mode  is  as  a  single  machine  in  a  separate  ;er  used  to  aggregate  mul;ple  XenApp  or  XenDesktop  sites.     The  last  mode  is  a  development  of  the  single  server  in  that  mul;ple  servers  are  used  together  in  a  group  to   provide  high  availability  for  the  deployment   In  these  laWer  two  deployments  Storefront  is  administered  separately  from  the  back  end  sites.  
  12. 12. © 2014 Citrix. Confidential.12 •  Mul;ple  servers  can  be  deployed  together  in  a  Storefront  ‘server  group’  behind  an  external  load   balancer  that  provides  a  common  address  to  the  clients.  All  the  servers  here  are  iden;cal  and  can   service  any  request  from  a  Receiver.  ARer  the  user  has  been  authen;cated,  their  authen;ca;on  details   are  replicated  to  all  servers  in  the  group  in  the  encrypted  ‘creden;al  wallet’.  Similarly,  any   subscrip;ons  the  users  make  to  their  applica;ons  are  replicated  around  the  servers.     •  Replica;on  is  also  used  to  distribute  configura;on  changes  made  at  any  one  of  the  servers   automa;cally  around  the  rest  of  the  group.  
  13. 13. © 2014 Citrix. Confidential.13 •  A  significant  difference  between  WI  and  Storefront  to  understand  is  their  rela;ve  deployments  when   considering  remote  access.  The  normal  WI  model  is  to  have  an  external  site  to  hande  remote  access   and  an  internal  site  to  handle  users  on  the  LAN.  Both  will  normally  aggregate  resources  from  the  same   set  of  back  end  providers.  
  14. 14. © 2014 Citrix. Confidential.14 •  Storefront  takes  a  different  approach.  Rather  than  maintaining  two  sites,  Storefront  understands  that   some  connec;ons  may  be  made  externally.  It  can  detect  that  connec;ons  are  made  remotely  through   the  gateway  by  looking  at  headers  on  the  network  protocol.  Storefront  will  then  arrange  to  sign  on  the   users  automa;cally  by  a  trusted  rela;onship  with  the  gateway  and  ensure  that  HDX  launches  are   routed  through  the  gateway.  
  15. 15. © 2014 Citrix. Confidential.15 •  This  close  rela;onship  for  Storefront  and  Gateways  can  be  used  to  help  configure  Receivers.  Storefront   exposes  an  ‘Account  Service’  through  which  a  Receiver  can  pull  a  bundle  of  configura;on  informa;on   that  can  be  subsequently  used  to  drive  access  to  the  Stores.  Access  to  the  account  service  is  arranged   in  a  simple  manner,  needing  the  user  to  only  provide  a  single  server  address  or  their  email  address  or   to  click  on  a  ‘provisioning  file’  that  is  generated  from  the  Storefront  admin  tool.  The  administrator  will   setup  their  gateway  to  pass  on  any  account  service  access  and  can  configure  DNS  records  to  provide   the  email  address  form  of  access.  
  16. 16. © 2014 Citrix. Confidential.16 •  A  popular  deployment  mode  with  WI  deployments  is  to  use  the  same  network  address  for  both   internal  and  external  sites.  This  is  convenient  as  it  means  that  users  using  browsers  need  only  need  to   remember  /  bookmark  a  single  address.  Storefront  and  NetScaler  gateway  can  also  support  this  model.   We  have  been  cau;ous  about  declaring  support  for  it  as  there  were  issues  with  iOS  Receiver  working  in   this  mode  but  these  will  be  addressed  soon.   •  Na;ve  Receivers  use  a  ‘beacon’  point  to  determine  whether  they  are  located  internally  or  externally.   By  default  this  is  the  address  of  the  Storefront  site.  For  this  single  FQDN  mode,  this  must  be  changed  to   the  address  of  a  different,  internal  only,  highly  available  site.   •  If  Account  Discovery  is  needed  externally,  config  on  the  gateway  can  be  confused  if  the  same  address   is  used  as  (apparently)  the  gateway  itself.  Use  instead  an  alias  for  the  Storefront  address  that  is   available  in  DNS  and  representa;ve  on  the  Storefront  SSL  cer;ficae.  
  17. 17. © 2014 Citrix. Confidential.17 •  Another  popular  deployment  mode  is  to  use  Receiver  to  access  a  published  desktop  and  then  within   that  desktop  use  Receiver  (PNAgent)  again  to  access  published  applica;ons.  Ideally  though,  if  the   applica;ons  are  available  locally  within  the  desktop,  they  should  be  started  locally  and  not  use  a   second  hop  connec;on.   •  In  the  XenApp  IMA  world,  this  was  achieved  with  a  call  to  ask  IMA  if  the  applica;on  was  published   locally.  If  it  was  then  the  startup  informa;on  was  returned  for  local  launch  and  if  not,  a  second  hop   was  used.   •  That  method  worked  well  when  there  were  rela;vely  few  RDS  servers  but  does  not  work  so  well  when   there  may  be  many  thousands  of  desktop  machines  in  the  VDI  world...  
  18. 18. © 2014 Citrix. Confidential.18 •  To  replace  this  model,  checks  are  moved  up  front.  When  Receiver  looks  for  the  available  applica;ons   for  a  user  in  order  to  create  shortcuts  for  launching,  it  checks  the  applica;on  details  for  a  ‘prefer’   keyword.  If  that  keyword  exists  and  its  value  matches  the  name  of  an  exis;ng  local  shortcut,  Receiver   knows  that  the  local  app  is  ‘preferred’  and  leaves  the  shortcut  alone  so  local  launches  are  then   automa;c.  If  there  is  no  shortcut  match,  Receiver  prepares  a  shortcut  that  will  do  a  second  hop  launch.   •  Where  some  people  liked  to  clear  the  Start  menu  of  all  shortcuts  and  let  Receiver  populate  it,  the   above  won’t  work.  We  will  have  a  Receiver  release  soon  that  will  support  moving  these  shortcuts  to  an   alterna;ve  directory  instead.  Receiver  will  then  look  there  to  determine  whether  to  create  a  second   hop  shortcut  or  restore  the  local  one  
  19. 19. © 2014 Citrix. Confidential.19 •  Another  component  that  Storefront  works  well  with  is  HDX  Insight  where  all  HDX  traffic  needs  to  be   routed  through  the  Insight  enabled  gateway.  In  the  event  that’s  not  the  same  gateway  that  the  user   connected  to  Storefront  through,  configura;on  can  be  applied  so  that  the  HDX  traffic  is  re-­‐routed  to   the  desired  access  point.   •  Note  this  re-­‐rou;ng  method  is  also  applicable  to  other  mul;  gateway  scenarios  where  it  is  op;mal  for   the  traffic  to  flow  through  a  par;cular  path.  
  20. 20. © 2014 Citrix. Confidential.20 •  Storefront  has  been  developed  in  the  knowledge  that  deployments  can  be  complex.  It  can  cope  with   the  challenges  above  either  automa;cally  or  with  configura;on  changes,  be  op;mised  to  work  with  all   kinds  of  deployment  challenges.  
  21. 21. © 2014 Citrix. Confidential.21 •  A  common  scenario  is  to  have  mul;ple,  homogenous  sites  providing  apps  and  desktops  to  users.  This  is   done  for  HA  and  for  Scale  Out.  We  need  to  be  sure  though  that  the  users  are  not  presented  with   mul;ple  icons  for  these  resources.  By  marking  the  sets  of  providers  as  being  aggregates,  Storefront  will   de-­‐dup  any  resources  before  presen;ng  to  end  users  
  22. 22. © 2014 Citrix. Confidential.22 •  If  you  have  mul;ple  sites,  they  may  well  be  geographically  dispersed  or  be  of  different  capaci;es.  In   this  case  it  may  be  desirable  for  Storefront  to  ask  a  more  local  site  for  resources  before  a  remote  one.   The  admin  can  set  a  preferred  order  onto  provider  queries  to  support  this.  Alterna;vely,  if  all  sites  are   equal,  Storefront  will  use  a  randomised  order  for  querying  providers  to  help  spread  the  load.   •  You  may  also  have  a  DR  scenario  where  an  alterna;ve  site  is  available  for  use  in  case  of  major  outage   on  your  main  sites  (but  would  not  normally  have  to  take  that  level  of  load).  In  this  case,  a  provider  can   be  marked  as  failover  only  and  will  only  be  used  in  the  event  that  other  sites  are  not  available.  
  23. 23. © 2014 Citrix. Confidential.23 •  There  is  an  excep;on  available  to  this  site  level  ordering.  In  some  circumstances  it  may  be  op;mal  for  a   par;cular  applica;on  to  execute  in  a  specific  site  (eg  as  it’s  near  to  its  database).  You  do  not  though   have  to  change  considera;ons  for  all  other  applica;ons.  In  the  example  shown,  the  desired  eval  order   may  be  1  -­‐>  2.  If  the  special  app  ideally  should  execute  in  site  2  however,  it  should  have  a  ‘primary’   keyword  applied.  This  will  influence  Storefront  to  route  connec;ons  to  that  second  site  for  that   applica;on.  If  the  second  site  is  not  available,  it  will  then  use  the  app  instance  from  the  first  site.  
  24. 24. © 2014 Citrix. Confidential.25 •  Storefront  2.5  introduces  parallel  enumera;on  for  mul;  sites.  Queries  are  sent  to  all  sites  at  once  and   the  responses  aggregated  when  received.  This  should  speed  up  queries  for  environments  where  many,   diverse  back  end  providers  are  used.  
  25. 25. © 2014 Citrix. Confidential.26 •  On  the  server  itself,  for  those  used  to  WI,  there  are  differences  to  the  layout.   •  Each  service  within  Storefront  has  its  own  directory  under  wwwrootCitrix.   •  There  will  be  a  directory  for  every  Store  (where  many  config  items  are  available  in  the  web.config  file   and  ICA  template  file)   •  There  is  a  separate  directory  for  the  Receiver  for  Web  site  (by  default  this  has  the  name  of  its   associated  Store  with  ‘Web’  appended.  
  26. 26. © 2014 Citrix. Confidential.27 •  Storefront  has  a  dedicated  area  of  the  eventlog  called  ‘Citrix  Delivery  Services’  where  major  issues  are   logged.   •  You  can  also  enable  detailed  tracing  via  powershell   •  A  simple  means  of  checking  that  a  Store  is  alive  and  has  appropriate  configura;on  is  to  load  the   ‘discovery’  document  from  a  browser.  This  is  what  Receivers  do  when  they’re  accessing  a  Store.  The   file  downloaded  will  be  called  discovery.cr.  It  isn’t  however  a  correct  provisioning  file  document  so   don’t  just  double  click  it.  Instead  open  with  notepad  or  rename  to  be  a  .xml  file  to  make  it  easier  to   read  in  a  browser  or  specialist  tool.  
  27. 27. © 2014 Citrix. Confidential.28
  28. 28. © 2014 Citrix. Confidential.29 •  Receiver  for  Web  is  a  website  and  can  be  customised  as  such...  
  29. 29. © 2014 Citrix. Confidential.30 •  ...by  using  standard  website  techniques  altering  CSS  and  Javascript  the  appearance  of  Receiver  for  Web   can  be  altered.   •  RfW  has  a  ‘contrib’  directory  into  which  the  CSS  and  JS  overrides  can  be  dropped  for  the  site.  This   directory  will  be  maintained  during  upgrades.   •  See  the  referenced  blog  ar;cle  for  an  excellent  introduc;on  to  Customising  Receiver  for  Web  
  30. 30. © 2014 Citrix. Confidential.31 •  Should  you  need  to  alter  the  business  logic  for  Storefront  itself,  there  is  now  an  SDK  available  to  help   you.     •  Note  that  simple  resource  filtering  is  now  (from  SF  2.5)  available  just  in  config,  but  where  changes   require  greater  reference  to  the  current  context,  the  SDK  can  help.   •  See  the  referenced  blog  ar;cle  for  more  details  
  31. 31. © 2014 Citrix. Confidential.32 •  These  are  the  modifica;on  points  exposed  by  the  customisa;on  SDK.  In  each  case,  the  customisa;on   point  has  the  model  that  the  code  is  handed  a  document:  e.g.  the  resource  XML  or  the  ICA  file.  The   customisa;on  logic  will  then  ‘edit’  the  file  and  hand  it  back  to  con;nue  being  processed.  Input  context   can  also  be  altered,  adding  Access  Condi;ons  or  edi;ng  the  clientname.  
  32. 32. © 2014 Citrix. Confidential.33 •  These  are  the  set  of  condi;ons  exposed  to  the  customisa;on  points  to  help  establish  the  context  for   making  changes.  There  is  full  informa;on  about  the  User,  the  device,  any  access  condi;ons  and  from   hWp  headers,  details  about  their  access  paths  and  plaporm  (from  User-­‐Agent).  
  33. 33. © 2014 Citrix. Confidential.34 •  Many  customers  integrated  applica;ons  from  WI  into  their  in  house  portals.  There  is  a  different   technique  required  for  Storefront  from  WI  as  the  previous  WI  SDK  will  not  work  for  Storefront.   •  To  integrate  Storefront  provided  resources  into  your  portal,  you  call  the  Storefront  services  via  the   ‘webproxy’  interfaces.  These  are  a  series  of  REST  services  providing  JSON  responses.  Different  services   provide  access  to  enumerate  resources,  obtain  the  associated  graphic  resources  (eg.  Icons)  and  to   launch  the  resources  or  discover  exis;ng  sessions  for  these  resources.  
  34. 34. © 2014 Citrix. Confidential.35
  35. 35. © 2014 Citrix. Confidential.36
  36. 36. © 2014 Citrix. Confidential.37
  37. 37. © 2014 Citrix. Confidential.38
  38. 38. © 2014 Citrix. Confidential.39
  39. 39. © 2014 Citrix. Confidential.40
  40. 40. © 2014 Citrix. Confidential.41
  41. 41. © 2014 Citrix. Confidential.42
  42. 42. © 2014 Citrix. Confidential.43
  43. 43. © 2014 Citrix. Confidential.44
  44. 44. © 2014 Citrix. Confidential.45 •  StoreFront  is  
  45. 45. © 2014 Citrix. Confidential.46 •  So  why  migrate.    Web  Interface  supported  on  XA  7  for  two  more  years.    Works  fine,  why  migrate.    Here   are  some  of  the  reasons  Customers  ….  
  46. 46. © 2014 Citrix. Confidential.47
  47. 47. © 2014 Citrix. Confidential.48 •  Windows,  Mac,  Android,  iOS,  …or  a  device  with  an  HTML5  browser.  
  48. 48. © 2014 Citrix. Confidential.49 •  StoreFront  does  add  Self  Service  
  49. 49. © 2014 Citrix. Confidential.50 •  Fully  leverages  Netscaler,  supports  all  the  mainstream  
  50. 50. © 2014 Citrix. Confidential.51 •  Clientless  access,  server  group  admin,  customiza;on  
  51. 51. © 2014 Citrix. Confidential.52 •  Will  help  you  modernize  your  deployment  

×