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

•  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
diﬃcult,
and
we
found

about
two
years
ago
that
it
had
become
too
diﬃcult
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

•  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

•  We
going
to
cover
these
topics

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

•  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
conﬁgura;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.

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.

•  Turn over to Simon to cover what you’ll need to know to deploy StoreFront in
your environment

•  Key
diﬀerence
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

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.

•  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
conﬁgura;on
changes
made
at
any
one
of
the
servers

automa;cally
around
the
rest
of
the
group.

•  A
signiﬁcant
diﬀerence
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.

•  Storefront
takes
a
diﬀerent
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.

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

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

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

•  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

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

•  Storefront
has
been
developed
in
the
knowledge
that
deployments
can
be
complex.
It
can
cope
with

the
challenges
above
either
automa;cally
or
with
conﬁgura;on
changes,
be
op;mised
to
work
with
all

kinds
of
deployment
challenges.

•  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

•  If
you
have
mul;ple
sites,
they
may
well
be
geographically
dispersed
or
be
of
diﬀerent
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.

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

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

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

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

•  Receiver
for
Web
is
a
website
and
can
be
customised
as
such...

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

•  Should
you
need
to
alter
the
business
logic
for
Storefront
itself,
there
is
now
an
SDK
available
to
help

you.

•  Note
that
simple
resource
ﬁltering
is
now
(from
SF
2.5)
available
just
in
conﬁg,
but
where
changes

require
greater
reference
to
the
current
context,
the
SDK
can
help.

•  See
the
referenced
blog
ar;cle
for
more
details

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

•  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).

•  Many
customers
integrated
applica;ons
from
WI
into
their
in
house
portals.
There
is
a
diﬀerent

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.
Diﬀerent
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.

•  StoreFront
is

•  So
why
migrate.

Web
Interface
supported
on
XA
7
for
two
more
years.

Works
ﬁne,
why
migrate.

Here

are
some
of
the
reasons
Customers
….

•  Windows,
Mac,
Android,
iOS,
…or
a
device
with
an
HTML5
browser.

•  StoreFront
does
add
Self
Service

•  Fully
leverages
Netscaler,
supports
all
the
mainstream

•  Clientless
access,
server
group
admin,
customiza;on

•  Will
help
you
modernize
your
deployment

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

Similaire à SYN224: Best practices for migrating from Web Interface to StoreFront Services (20)

Plus de Citrix

Plus de Citrix (20)

Dernier

Dernier (20)

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