>> Hello everyone, and welcome
to today's SharePoint Roundtable.
My name is Jim Adams,
and I'm a Business Program Manager
for the IT Showcase team,
and I'll be your host for today's session.
Today, we're here with some of
our intrepid SharePoint experts.
Let's take a moment for them
to introduce themselves. Sam?
>> Hi everyone.
My name is Sam Crewdson.
I'm a Program Manager here in the internal IT team
that manages Office 365 and SharePoint.
Among my current projects are
working around the new publishing sites,
communication sites, things around Dell,
Dell profile, audience targeting, that sort of thing.
So super happy to be here.
>> Soujanya?
>> Hi everyone, my name is Soujanya Srivalli,
and I'm a Program Manager with
the Enterprise Search and Finding
Experience here at Microsoft.
And I work on the Enterprise Search Experiences
on SharePoint and also the portal search experience,
and I'm very happy to be here.
>> Excellent. Darren?
>> Hi, I'm Darren Moffatt.
I'm a service engineer here at Microsoft.
I focus on Office 365 core automation
and SharePoint Online and Groups.
>> David?
>> I am David Johnson.
I am Program Manager for our Office 365 Shared Services.
Our strategy, and our solutions,
how we get our employees and
our businesses to build the right
solution from a full product stack.
>> Thank you everybody.
Before we get started,
I'd like to tell our audience that at any time,
you can ask our experts
a question by typing it into the Skype window.
I'll then anonymously read
that question aloud for our experts to answer.
If we run out of time before our hour is up,
we'll stay behind in the studio,
record our answers and
publish them on the on demand webinar.
Then we'll go into our Q&A panel,
and we will share our final key takeaways,
and with that, we'll get started with the first question.
So, let's see.
Sam, I'll start with
you because you're at the top of the list here.
This is a question that we got
from a little while ago before our session started.
What have been the challenges and benefits around
the release of communication sites?
>> So, communication sites, for those who don't know,
are something that we announced publicly last spring,
had a really big coming out party at Microsoft Ignite,
and it's been really
a fabulously successful program internally.
So it kind of worked backwards.
The outcome of the communication sites release
has been people who internally,
number one, they found it much easier to deploy.
There are a couple of our internal business partners
who have indicated that they went from being someone who
disliked SharePoint to being someone who loved SharePoint.
And why is that?
Number one, they were able to deploy
their internal site much faster.
They describe where the previous version of
their site took a couple of months to build,
and it took them hiring
an external consultant to
come in and build it and make it look nice.
She, herself, did it without
having to hire any external consultant.
So, number one, there was the cost savings,
and she was able to do it fast and easy,
and it was accessible,
and it was responsive and worked on any device.
The list of wins about communication sites
has been really quite lengthy.
So, really, I guess that's my answer is that it's easier,
faster, and it turns your SharePoint
haters into SharePoint lovers.
>> And I'd add to that to say
part of it is also the content.
It puts the emphasis of the experience squarely
on the content itself and making sure
that it's about offering quality material.
It's about making sure the presentation
of that material is solid,
that the kind of how you wrap
that story, which picture you are choosing.
That's where your focus is.
How do I tell my story?
What story and how to represent it with
a picture or something that's going
to summarize it effectively.
And I'm not as worried any more about building that site.
We used to, to Sam's point,
have a lot of, I guess,
portal build time, and there's a lot
of designs work around.
Okay, we're going to build these big, complex sites,
and it almost took away from
the core message of what is information architecture?
What is the content?
What is the structure to make it really
solid on where people want it to be as opposed to,
I think, that's what's really
changed fundamentally on going to communication sites.
>> And can you have a brand for division or something,
without going into a lot of customizations?
>> Oh Yeah. I think that's part of
the customization story for
communication sites continues to
evolve and one of the nice things,
and I think Sam, you can talk to this a lot more too,
is the new SharePoint hub model to say,
"Look, I want to put my, for example,
IT branded sites or legal branded sites
all under one kind of container so I
can have a hierarchy,
and more importantly, a nav
that's cross-site collection as well,
along with the sites specific."
>> Yeah, I'll add to that.
So, there are really three areas that
were announced publicly at Ignite and really touted.
Number one, hub site model.
So the idea is that you can have effectively,
what acts as a parent site,
and that's called the hub site and
then you can have associated sites.
That's the terminology,
but everyone in the world, I think,
is going to call them children or spoke sites.
And, basically, all these sites
associate up to this top level parent site.
And they inherit branding.
They inherent theming.
They inherent search.
This common since it was called the site hub site ID.
So search from across
all these sites is aggregated in one place.
And then the other thing,
and while I'm talking about all my favorite features here
in this first couple of minutes of the session,
is the new site design templates,
something we call internally
recipes until just recently,.
The idea being that you'll be able to lay
down your web parts,
what libraries you want to build.
You can integrate it with flow
and take actions based on site creation,
based on something built in flow.
So there's so much exciting work being done in
the modern space and in
communication sites in particular.
I would really encourage everyone to give it a whirl.
>> One other piece about that is just the,
when you think about the sites inheriting
the nav from this almost parent hub,
it's not like where you historically would have
had one giant site collection, say,
everything's under this structure,
and it's really formal and you have to manage it,
all the complexities having everything in one thing.
Now, you let the individual teams build their own sites,
their own team sites, their own communication sites.
These are top level site collections are
getting created all that with
the ability to interconnect them.
>> Okay. So, David, since you have the baton,
since all of your SharePoint online data
for Microsoft is stored in one data center in the US,
I guess, they're assuming that it is,
do your regional users have performance issues?
If they don't, how do you manage that?
>> It's a fair question, and so there's
a couple of pieces there.
One, not all of our data is going to be in the US.
We are in process and,
Darren can talk about this more too,
of moving toward a cross-geographic model,
where we will have parts or tenants
will be in various regions, so it's kind of part one.
So sites will be closer from that perspective.
Part two, we use for
content delivery network
on within the product itself,
the CDN, to automatically
move certain types of files closer to the individual.
So things like core structure,
CSS, Javascript images on the page.
Those things aren't necessarily going to come in
from the US data center.
They're going to be coming from a
closer region to where the individual
sits because they're all on a CDN replicated worldwide.
So, therefore, it's going to come from a close space.
And that's I think two of kind of key points to this.
And I think a third point is that,
there are so many factors performance,
especially with geo.
Yes, these are our big contributors,
like we've had massive increases in performance.
Some of our portals sitting in the US,
by people outside of
the US partially because of
who we are really, I think dramatically helped.
But part of it is also just understanding
the last mile, your network connection,
the internet where you are too is
a strong foundation for part of this.
>> And actually I'll jump in,
and then we'll give it to Darren.
The thing I would add on
to your CDN piece is that you can control,
you can set policy for
your CDN based on site classification.
So, for example, we have
three primary site classifications internally,
used to be called LBI.
It's now called General,
and that's just basically your basic,
everyday business content, nothing super secret about it.
Our next level up is confidential,
and, as you might imagine,
that stuff that we were especially
careful about not leaking
publicly and then highly confidential,
which kind of think about it as top secret.
And I just wanted to add on that we have configured
our CDN such that the General sites,
that's the new name,
essentially, will replicate everything.
All of the various file types and what have you,
out to a unauthenticated CDN,
and that's going to be the fastest way of doing things.
Now, we have the second level up
the confidential sites will enforce authentication.
So all the things that are replicated out to the CDN,
ensure that it'll check your credentials is the gist.
So, that way, someone
can't send out a link to the content.
And then, finally, for our top secret sites,
our highly confidential sites,
we disable the CDN for those.
So my point is it's inside of your control whether to,
number one, enable the CDN, and, number two,
you can apply policy to what types of
content and what kinds of
sites get replicated to that CDN.
>> And to be clear,
by the way, we're also adding to that,
we're talking about structure of the site and graphics,
not necessarily documents on it.
So, of course, secure content that
might be on the site is not impacted by the CDN.
> So, Darren, the follow on to that is,
do we have now
the much requested multi-geo
capability in our enterprise?
>> Yeah, we do.
We're in the process of rolling it out.
That means ensuring that the
280,000 user accounts we have in Microsoft,
they're properly coded with
the correct preferred data location.
That's something we're still in
the process of doing simply
because there are more
than just SharePoint in these moving parts.
We have to be very mindful of Skype for Business,
Teams, Exchange, SharePoint Online.
Setting the PDL can potentially cause
you and your mailbox to
be moved to a region you don't want it to be.
It could cause issues with dialing plans.
So those are some of the challenges we
are we are supporting and we're facing right now.
In the SharePoint space,
the other thing we're working with is
our network teams to
understand where the data centers
are going to be located in our geos.
In this case, it's Dublin and Singapore.
And more specifically, what can we do to
reduce the amount of hops that
users from say China, or Japan,
India, the UK, for instance,
those types of hops so that they can get to
the geo data centers more efficiently.
And so there is a lot of fine tuning that has to go on.
And we do see, as David mentioned,
we are seeing some performance gains,
although our intent with
Multi-Geo and supporting it was more data sovereignty.
>> Yeah, and that's what I was going to
say is that if our product group friends were in the room,
they would explicitly say that going Multi-Geo,
you don't do that to get performance,
although that might be a side benefit.
That the real reason we do it is around policy.
>> Data sovereignty.
>> You're keeping content where it belongs.
>> Sorry, I just wanted to.
>> No, and that's a very good point.
The expectation with Multi-Geo should not be performance.
That's not to say that you wont get performance.
The-out-of-a-box deployment of Multi-Geo
there does require some fine-tuning.
I mean, I can't speak for every business out there,
but I know that depending on where
your offices are located,
who your internet service providers
are for those commercial locations,
there maybe have to be some tweaking
between the different data providers
and bandwidth providers.
I know that our NIS team
basically spends their entire existence fine-tuning,
constantly optimizing our network.
So, there is performance gains
to potentially be had if you're a customer, for instance.
It's like hitting a data center in
the United States is always going to be a challenge
for me just based on the nature of my setup.
If only there was a place in Singapore I could go,
then you may see some performance benefits
beyond what type of
engineering you can even do to
get to the US data centers.
But as Sam pointed out,
the primary reason we went
Multi-Geo was data sovereignty and ensuring that we
could have content where
I guess legally and logistically,
have it belong where it should,
which is in the Geo's that
those particular offices reside in or around.
>> So does this entail
most general content or
just specific pools of data that were?
>> The grand scheme is general content.
>> So, the typical road warrior
scenario where a US traveler
can get their content from
the most local data center
as opposed to going all the way back to the States.
>> And that's covered by
the CDN strategy that Sam and David talked about.
When we look at prefer data locations and Multi-Geo,
the scenario would be if
that particular employee was say,
going from the United States and maybe
spending a month in say another country.
>> Like in China.
>> Yeah.
>> Or Singapore.
>> If they're working on something that
was potentially legally binding or government contracts,
then we may have a case to say, all right,
set their preferred data locations to Europe or Asia,
and then we will go through
the process of moving their mailbox,
they're moving their OneDrive there,
and then their data is in there.
Should they come back to the United States,
then we have the ability to reset
their PDL and move it back.
Although given all the moving parts there,
it is kind of one of those things that with Multi-Geo,
our strategy is moving
preferred data locations for longer term needs.
Shorter term needs, I feel,
are being served by the
content delivery networks or CDNs.
>> In the same client?
>> Yeah. In the same clients. Yeah.
>> That we generally have in
region, the employees' mailbox.
If you're a European employer,
mailbox will be in the region,
your OneDrive will be in the region.
In any new group, SharePoint connect
and SharePoint that you
create will be in that region too.
>> Yup.
>> And in that,
that was actually the thing I was going to
jump in and also say is,
when they're creating a regular SharePoint site,
the person doing the site creation,
it'll be created in their preferred data location.
So, if you're an international team
and you want your site to be created in Europe,
you should have one of the guys in
Europe execute that site creation
or reach out to your IT team where we can do it for you.
Or your IT team.
>> Okay. And so.
>> Yup, go ahead.
>> All right. What is the most exciting,
what are the most exciting things coming
to the search experience? I will give it to you Soujanya.
>> Okay. Yeah I think since we're on the Multi-Geo topic,
I think we'll start with that right?
>> Fantastic.
>> So when your OneDrive for Business or
your SharePoint sites are
created in these various regions,
it's very exciting to know that you will have
one search experience that you don't
have to go to multiple locations,
multiple regions for getting your content, right?
That's I think a big
plus with the whole Multi-Geo experience.
And gladly, for us within Microsoft, it's already there.
We already are in this Multi-Geo experience,
which means when Darren
and David and Sam and everybody work
on the experiences of
moving all of the content to these various regions,
we still have one enterprise search experience, right?
I think that's very exciting.
We don't have to really worry about, "Oh,
I'm not finding my content in
Asia or in any other region."
I think that's exciting.
The biggest excitement I think
is about the personalization in search.
Right? It's always been a request for users,
they're like, "Can search know me?
Can search know I am this employee?
I work in this space and this
is my interest and all that."
I think it's coming together in a great way,
in all of the search experiences.
So when you go into the new enterprise search experience
or when you go into a new portal search experience,
it now knows you as a user,
and it knows what your connections are,
everything powered by the Microsoft Graph
that you might have heard at Ignite.
Right? And so it already knows that, okay,
this is my team,
that I'm working with them, right?
And it surfaces the content that will be interest
of within my network first,
and then go deep dive into the other content,
and I think that's the most exciting thing that's
coming up in search to look for, yeah.
>> Yeah. And one thing that's exciting,
that's super cool to having worked
on search for a number of years is you
start typing into the new search box
and it's just giving you that predictive behavior.
And by predictive, I don't mean what we see on
public search engines where it's
kind of a smart auto complete.
But rather, the suggestions that come up right in
the search box are graph driven now.
>> Yeah.
>> Yeah. So, it'll show you content
based on the people around you,
the people you interact with,
content you worked on recently.
All that is taken into account
and right from within the search box,
even without having to execute your query,
you start to see that stuff show up.
>> And this a value also of
the collaboration type search because typically,
busy unmanaged content and unstructured
stuff that people are putting in their team sites,
their OneDrives, their groups,
or my team, Microsoft teams,
it's that content that you don't think put
a lot of thought into it
because it's really for your peers.
And so, this new experience brings that
up and I think that's
kind of changing the dynamic of saying,
"You know what, this content was before
hard to find because it necessarily wasn't managed,
it wasn't the authoritative content."
It's now much more discoverable
because of what you're talking about.
>> Right.
>> And I know it wasn't aimed at me,
I'll just jump in on this question a little bit too.
One of the other things that we announced at Ignite is
the the AI and the image recognition.
So, the search engine in
Office 365 was going to be all to
read the EXIF data and your photos.
And you're like for example,
if you search on the word
Iceland, it was the thing that they demoed at Ignite,
it will bring up pictures that were
taken in Iceland or
it'll be able to read the contents of the file.
So if you're looking for
a receipt and you've typed the word steak,
and steak was on the receipt,
then you'll find that receipts via
the content found within the image.
So, that's something that's
just rolling out for us here,
and coming to the world soon,
and that's something that I think is really exciting.
>> Yeah. And I think just to add to that, right,
I think the refresh of
the search experience itself
is also a very exciting thing.
There's a new UI, there's new metadata that you see,
and we've always had like,
"Can I see the modified date on this content?"
It's a very simple thing in content discovery.
"Can I see who modified it last?"
So it's all coming together in terms of a UX refresh also,
which is cool. Yeah.
>> Depending on whether you're in
a 100% cloud environment or a hybrid environment,
is the search experience the same or different?
>> So, we are currently in a hybrid environment.
And what it gives us is,
actually, to answer your question, yes.
They will be the same as long as
you have a cloud component,
the experience will be the same.
The additional benefit of hybrid search is of course,
the story of whole connectors,
that they are now able to
connect to external data sources that are
not inherently part of your SharePoint online experience,
and hybrid gives us a great way of
blending that content into the SharePoint experience.
>> Okay. Plus of course,
they gave us the ability to move.
Over time, the cloud, we agree by having hybrid in place,
it meant that the on-premise
sites weren't isolated anymore, they're discoverable,
they're part of the enterprise
set still and I think that for us,
it was a big deal when we moved to bring in hybrid.
>> Okay.
So, let's see.
We have a few people that went to Ignite
2017 and this is from Ignite. A question.
At Ignite, it sounded like that
Microsoft was moving away from subsites.
If that's true, how are you managing that internally?
>> I guess, that, that might be mine, first.
So, yeah,
there's definitely a de-emphasis on the old way.
So, you used to be, you go out,
You build this, monolithic site collection.
You build your content.
Narrow and deep, is how I'd like to think about it
With a lot of subsites,
And maybe, subsites under those subsites, and
Really, that was kind of our old way of doing things.
Now, if you went to Ignite or,
If you watched some of the sessions,.
Ignite.Microsoft.com by the way,
then, you can see that the product group is moving
in a slightly different direction. And
I referenced this earlier.
So, the new model is, to build, a lot of,
top level site collections, and then
associate them together, via the new hub site feature.
The new hub site feature, gives you.
The ability to aggregate search across all that content.
The ability to have a common nav
across all that content,.
So, you can see,
that this might be the way, for example,
you, build the divisional, site collection in this case.
So, you might have your,
HR, top level communication site,
but then associated, to that top level site,
you might have a mixture of
modern group space team sites,
as well as additional, communication sites,
and those can be associated up, to
the parent, and inherit that search: theming,
branding, all that stuff that we used to, have to do
Within a single site collection boundary.
>> The other thing I'd add to this is that,
when we think about, groups,
versus basically, a flat structure,
it's also about the security boundary.
That, part of the, advantage, of
having a much more, breadth-focused, structure,
is that you're saying, "I'm going to
have my boundary being, who I'm working with,
who's my team? And, who am I, typically
coauthoring with on a general basis."
Though, that's the people that
should have access to the site,
as opposed to, I think,
part of a challenge, we've seen internally anyways,
is, a depth, site,
with a lot of subsites,
the risk of people, unintentionally
are not understanding,
like a breakaway permissions
and unique inheritance, understanding all that.
And I think that's
the nice thing about the flat structure,
is the permissions, of a group,
is, permissions of the site
to start that's where boundary.
If I want to go beyond that,
I can still, of course, share a file, share a link.
And, that group boundary
also persist to the other workloads.
That's the group boundary for Microsoft teams.
That's the group boundary for Yammer, connected groups.
That's the group boundary for the DL,
perfectly, for, the calendar, for planner.
All these pieces, fit together, for that group.
So part of the advantage of, moving from
the subsite model and breadth model with more groups,
it's just, you get the advantage across the Office 365 suite.
>>And I would add on to that.
One of the things that as an IT guy,
one of the things I'm really looking forward to with
the new, hub model is,
best whole as a quick story.
So, unlike any other customer in the world,
I'm sure, you'll hear
that at Microsoft we go through reorgs constantly.
So, a team will get renamed, you know,
half the team will go to this new organization over here,
half will go to this organization over here.
And, what that leads us to is
this mismatch of our internal site collections with,
the organizational structure.
And so, what that then becomes
is this migration project, and
that we have to pull the site apart
and, establish new names, and,
you know, it really is kind of a mess.
One of the things that I foresee,
it's too early to say for sure that it's going to help.
But, what I'm thinking about is, with this, you know,
hub, and child, site-type model, is, that,
if you're very careful
when you're building out your sites,
it's super easy to, de-associate
your child site from
one hub, and associate it with a different hub.
Or to, de-associate your site
from a hub, and establish it as its own hub.
And so, you know, if you're very careful about,
the organizations and then underneath that teams,
or, like for us here at Microsoft,
this might be products, and then
teams, working on aspects of those products.
It gives you a way to, reassociate
and refactor those sites,
without having to rebuild,
and remigrate, and all that kind of jazz.
So, I think that's gonna be, for us one of
our bigger benefits of the hub site model
in addition to all the other things we said.
>> Yeah. Can I add to that?
Actually, one of the things that we've always
had challenges with nested sites, right?
That there's no easy way for us to move a site from
one site collection to
another site collection, for example.
I think the hub site concept is great. And
that way it's a flat structure, that you
will have now seamless way of moving
sites across, different divisions or different segments.
Like Sam spoke about and I think
that's the great thing about the hub.
>> Plus, for your divisional search,
that's going to be a big deal for a lot of
our internal customers and saying look,
"I want a legal search.
Now by associating them into one hub,
I can get a legal search."
>> So we're talking about hubs, sites, teams.
Here's a question that I've, overheard,
in the past we had, team sites,
with portal sites, and that was,
relatively easy to keep them, straight.
Now, we have team sites again, or teams,
what's the difference between Teams,
today's team, and the old, team site?
>> Okay. Well I can start with that one.
So, a Microsoft teams,
think of it as,its the chat and
voice meetings, components, on top of,
I was mentioning groups earlier,
it's that groups, thing, that
construct, and that, basically it's a SharePoint site.
You've got a SharePoint site, where I
got that is a team site.
That we you go create, a new team site in SharePoint now.
You're creating that group site,
connected site, which then,
can have teams on top of it.
So, every time we think about teams,
you actually have a SharePoint site,
and that is, the term saying, SharePoint team site.
So, I don't think, that's the confusion,
that, people need to understand, that
it's not an or, its an and.
You don't choose, teams or SharePoint.
By choosing teams, I have SharePoint.
Now, that's one option, the other option of course,
if I don't want, that team experience,
I want a portal experience.
In which case you're going to the communications site.
So, when we think about,
creation of sites internally now,
95 percent of our sites
are going to be group connected team sites,
groups connected to SharePoint sites.
The other, roughly three or four percent are
going to be probably
the communication sites, bigger portals,
and then we still have, some subset of
sites are still being provisioned, as classic,
non-modern sites, we like to think about them.
>> Okay. Thank you.
>> So David, how does
SharePoint Online security stack
up, to SharePoint on prem?
>> Interesting question. So, you know,
we've done a lot of obviously, like any customer,
we, internally have a lot of this
highly sensitive data that we have
to worry about, understandably.
And, so, big part of
this is trying to say how do we protect
our data, and, same time, how do we
make it so that our employees can
do what they need to do.
And so, when we think about those kind of,
core things, of, encryption
at rest, encryption in transit.
All kind of a core components,
IRM, customer lockbox, the auditing.
There are things, that only
exist, from a security perspective on
365, that would either be really
hard to do on
prem, or expensive to do on prem. It's doable.
I can even build a vault in it.
I can put a SharePoint file on
on-prem vault and make it really secure.
But, I've got two problems of that.
One, it's expensive to have set up.
And two, it's harder
for my employees to actually use the thing,
which means they're less likely
to use so, potentially, gonna
violate, by pulling content out, working from outside.
By working on 365, I've got, all the controls
baked in in, including,
the auditing process, which is a huge one isn't it?
I mean, we use auditing a lot, to
help us kind of, investigate, what's going on.
Not to mention, all the core, trust, foundation,
of a suite. That makes it.
So that, we are able to, kind of,
run in a much, better model.
And I feel that, we're at the
point where were saying, look,
we feel more comfortable of
our highly secure sites, being on Office
365, than we do
on prem, because our employees are going to,
first of all that the core
infrastructures that are going to protect them,
plus, the fact that they're there,
means that they are not,
the employee can actually make use of a thing.
And, yet we still protected from, device scenarios.
For example, we can still give
a conditional access checks to go.
Do we trust your device against your site,
if we don't, we're not going let you into the site.
So, you know, we still have the,
I think all those protection models,
plus, we can block, download, of content and say,
'you know what,
this content is going to stay on the site,
is not allowed to come down to the machine,
a local device, I can block OneDrive sync.
I can block SharePoint sync.
I can block, on my client, edit.
So there's all the things I can do, to make sure that
my sites, are far more
secure, in cloud, that it ever was possible on prem.
>> Excellent. Okay, we have another question from online.
I guess this one's for you.
Are you going to be able to
search across, multiple hub sites?
>> Yeah, I think the short answer is probably yes.
And search is, the way
search works as it's scopes, and you can
scope it to your, hub site
or, externally scope it to be on, the hub sites, right?
And it depends on how you want to configure.
One thing I want to be very clear here is that,
the hub site search, is still evolving,
it's not fully baked yet.
So there might be some scenarios
today, that's possible in
classic sites that are
still not supported in the hub site,
but it's coming up there.
So we will have that, at some point.
>> You know, I'll lay it out there. The implementation
of hub site is, through,
what's going to be essentially a managed property.
So, for example, if you go to
Ignite.Microsoft.com, I will plug that again, and look
up a session by Kathrine Hammervold, and, Naomi Moneypenny.
If you look really closely,
when they're demonstrating, the model,
you'll see that it has, I don't remember
the exact, syntax for it. But it has a hub site ID.
And so, conceptually, the idea,
is because this is just another crawled property,
if you want to, use that crawled property, if you want to
discover, and, reuse that
in your highlighted content web part,
in your content by search web part,
or, wherever, you know,
your favorite way of doing
searches, in your classic search center,
at least conceptually, you should be
able to build, whatever experiences
you have, to, aggregate, multiple hubs.
Now, this isn't a question that was asked,
but I'll make sure it's clear, just in case.
Today, the hub, model is, one level,
So one parent, to, multiple, children,
to, multiple associated sites, is their terminology.
So, you can't have, then,a
multiple hubs associated in a second,
or third, or fourth level.
That's something that they're considering, but right now,
they're focusing on just one level of
hub sites, so you can get that out the door.
>> Okay.
The questions coming in.
This one looks like it's for Darren.
Is the content on your portal,
limited to what, your team creates,
or can you include additional,
SPO content for your users?
SharePoint online content, for your users.
>> When you think about the current state of SPO,
we've got more ways, to include content,
or, our users.
And I think we've ever had before.
You've got things like, the corporate app catalog,
you've got, generally, the SharePoint app store
and, overall, includes a ton of content.
We've had hub sites, which we've just discussed
and of course, web parts. And now
internally, we've got web parts
that are out there as well
as being developed, that allow us, to say,
'here are some contents you can either
add to your site, or already include it.
>> So I think when you look at the big picture of things
and where SharePoint was,
where it used to be, what we went from
fully trusted code solutions,
which were all very tough to manage,
often broke,
had to be something we are incredibly mindful of,
to the Sandboxed solutions,
which typically had to
be deployed by the users themselves.
And again, there was a lot of supportability there
that we had to take into account.
So now, where we've got hub sites,
which plain and simple,
makes it easy to get content out to
our users as effortlessly as possible.
We've got the apps, which allows
a very structured approval process,
which allows us to get a great assortment of
apps that do a lot more
than our previous solutions ever did.
And then, of course, the web parts,
which allow us to get very structured content,
as Sam said, content by queries.
And we've got some web parts that are coming.
Maybe there's a few you want to add there
that allow us to just let our users do more.
>> And especially modern,
we've got the highlighted the content part, for example,
that brings content across sites, the classic,
you've got the content by search parts.
You've got the ability to add PowerApps,
by the way, to your sites. You can say, "You know what?
I want to embed a PowerApp,
which is going to surface content from
some other REST API or
some other service running somewhere
else and bring it all in."
>> So that's the definition of PowerApp?
What is the definition of PowerApp?
>> Actually, I don't know the best way to describe it.
A PowerApp is almost like a lightweight player for
this developer business lead application,
which is simply a UI.
It's almost like saying, "In Excel,
I can build these complex forms,
I can do a bunch of stuff."
It's basically saying,
I'm as the person building the PowerApp,
want to say, "Here's where I want to point the data to.
I've got these other services.
I want to connect to them to get the data.
Here's the form that I want to service it
in or here what I want to collect."
I can just quickly put my UI together and, as a business,
as a power user effectively,
I can build that PowerApp,
connect it to other things,
drop them to site.
Now, I've got this interconnected experience,
or I can still build a SharePoint web part,
either with provider-hosted part,
which we've been doing or
now the SharePoint framework parts,
which are all client side solutions effectively.
>> I'll just riff on that.
The SharePoint framework parts is, I think,
anyone who's seen one of our previous sessions
is probably sick of me talking about it.
But it's a super cool way of
doing web parts going forward because number one,
no longer do you need to have a certain level
of SharePoint knowledge to build these web parts.
It's using really off the shelf type of skill sets,
JavaScript, TypeScript,
Angular, Angular 2 and so on and so forth.
You can go out and build your client side web parts
in these well-known infrastructures.
You can deploy them easily to
your environment and make them available on your sites.
You can scope them to a security groups where
only limited users can see them or you
can make it so all users can see them.
So the development model for
most scenarios in SharePoint has
gotten so much easier and so,
that's something that we're working
heavily in my part of the team
right now to build out
the internal gallery for our internal users.
Now that said,
just two days ago I think,
we announced 20 new additional web parts
that are now available in the gallery.
Three days ago, right?
Recently. And so there's been
new releases on Twitter and the new Yammer web part and
an RSS feed web part and
all these things that you need to have to
build a robust powerful SharePoint site out on SPO.
And so between that and the new web part building model,
the sky's the limit.
>> And these are all shareable across the enterprise?
>> These are all shareable.
So actually, I'll answer your question directly,
but it made me realize something else too.
Yes. So you can put the parts up into the gallery
and you can make it available to all internal users,
or you can limit it.
So for example, if there's a web part built by
our finance team and they want to have
it only available to people in the finance org,
we can pinch it down accordingly using a security group.
Another thing where I thought you were going,
which I think is a good thing to bring up,
is there is also this open source community
that's really developed out on the Internet.
Where you can go out and get and download starters or
samples or in some cases
even fully baked web parts
that you just have to pull down,
maybe do some light customizations to your own needs,
compile those and put them up into
your own gallery and make them available
to your internal users.
So I'll put in a plug since I guess today is plug day.
There's PM internally in the product group, Vesa Juvonen,
probabaly massacring his last name I'm sorry Vesa.
Go out and find his web cast he does
it every week where they talk about new topics
and new solutions that they've made available
for our people to download from,
what is the name of the site that was- Patterns
and Practices websites.
>> Plus you can go to dev.office.com
and there is links to
Patterns and Practices content there.
>> Exactly. So from
an Enterprise tenant administration perspective,
is there any vetting of those PowerApps
and things that are in the gallery;
stamp of approval or things like that.
>> You or me.
>> Yes. Okay I'll take that.
So yes, for SharePoint apps.
So obviously the in product
ones are automatically available.
The ones that groups for example internally build we
vet because we just want to make sure is it a
solid are there any issues of
this, are we going to be concerned at all?
Is there any security implications?
So we vet those SharePoint apps,
and then they'll go into our internal galleries.
So there's- every company's tenancy
has an internal catalog
for private apps you want to build for
yourself and share them within your own company.
And of course the public one and so yes we vet
all the internal ones before we make them available.
>> Okay, another one.
Oh this one is loaded.
This one let's see.
Do users still call help desk here at
Microsoft and how do you resolve O365 issues?
>> I'll take that one. I mean yes,
they still call help desk
with a traditional telephone if they choose.
It is a much broader kind of scenario now.
I mean we've got ways to contact
our support staff through
things like Skype for Business, Teams.
We also have like online chat systems, Yammer.
The list is actually is pretty exhaustive.
We also have, we've deployed service now internally,
which actually does have a landing portal
for people to order things like smart cards,
to submit say AAD application requests.
I mean, even when it comes to support O365 issues with
wanting a custom application or
a custom solution, we've got front desk.
Which is a process that David helps support and drive.
So those are kind of
the different ways that we resolve O365 issues.
I know we've become a lot more social lately,
so some of the issues even get proactively
or I should say aggressively reactively resolved.
Basically we may have
a problem in O365 that we are very aggressive at
resolving simply because we're hearing murmurings
in Yammer or
we're experiencing it ourselves
and have that direct line with our support staff.
So we're hoping, ideally the goal is that
people still do call help desk but call help desk less.
Or rather they're calling us for issues that
aren't SharePoint is broken or O365 is broken.
It's more I need a smart card,
more positive experiences in
help desk are what we're aiming for.
>> And one of the things that Sam does a lot is,
we have Yammer groups because we do
a lot of community building internally.
In terms of making sure people peer is a practice,
people can help each other.
So internally we have
a SharePoint in Office 365 users group,
which is for that peer to peer knowledge sharing,
and we want to tell
people here's what's going on for ourselves.
And Sam, you do a lot of that.
>> Yes and that's where we might make
an announcement about maybe a new set of web parts that
we released internally or
my most recent post is about the
20 we just released publicly
being available to our internal users.
Going back to the original question about,
do we still take user help desk calls?
It's funny when I read the question on
the screen I interpret it a little differently.
So absolutely everything that
Darren said is absolutely correct.
We still have multiple paths for people to get to
our help desk and take action in that way.
I was wondering whether the intent of the question
was about whether we somehow funnel
users directly to Office 365
and bypass our support entirely.
And the answer to that one,
if that was intended the question, is no.
So we find that by having our own tier 2 team
be the aggregator and the one that
submit the tickets to Office 365.
They can usually help faster because
inevitably since we're part
of the test ring before things go public.
But not only for that reason, we'll see
10 or 20 of the same issues come up all at once.
And so they can work with what the product group
wants and then funnel that same answer out to
all impacted end users and see
that time on that ticket submission and response process.
So if that was the purpose of the question.
>> I think that speaks to the reliability of Office 365.
The reason or one of the primary reasons
we do have our own support team is
because I would say
90 to 95 percent of the issues that are escalated,
aren't necessarily around
the stability of the platform or
an issue that would be say Microsoft supported.
We're talking about Microsoft provider
not us as the customer.
95 percent of our issues are largely user education.
Either some internal process
and internal ordering process,
questions about potential content.
When you look at like our internal expensing systems.
>> Configuration leaves the permissions
wrong and why aren't things showing up in search,
things like that is-
>> The customer would want to own
and would be expected to
kind of own those types of things,
custom configurations as you
said we always we roll out more web parts there.
There is content there that we support.
So that's the- phrasing
it the way Sam interpreted the question.
Yes, we definitely don't
have a lot of people going directly to Office
365 for that reason because
our tier two team can resolve it so much faster.
And of course you won't have
that negative customer experience of
contacting Microsoft only to
determine that it is something
your administrators would have to have
dealt with in the first place so.
>> Many times it's like
community answers the questions also right like
the Yammer that David brought up
or the community groups that we have,
are very effective in
resolving some of your issues that are
common across various teams and various people.
That's probably for me,
I think it has been very helpful in that way.
>> I think the reason is,
our user base, our users out there are
the non phone users.
>> They're the ones that go to social media a lot.
And it's just the reality of the new work force.
>> I know I don't like telephone at all.
>> So yes.
All right. Another one.
>> This looks like a search one, what are the options
for targeting content through search?
>> Yeah, I feel this is an interesting question,
because many times we internally also face
the problem about targeting information
for certain people in maybe a region,
or a role and what not.
And I think one of the cool ways is that we have
internally implemented is by
using the user profile tokens.
The profile information has your role,
your region, and all that information.
And the way we implement is to create
result blogs that leverage the information
from your profile and dynamically
displays what content is, right?
The two things here, one is, of course,
the profile needs to have that kind of information,
and the second is the content
also needs to have that metadata,
and then we blend them together
and build this result blogs that are very
personalized and very centric
to that particular group of users.
>> Yeah, I'll riff on that a little bit.
As a real world example,
probably the most visible way that we use audience targeting
in today is on our internal corporate portal, MSW.
So, a visitor going to the front page of our internal,
this is sort of, corporate news portal,
for those who haven't heard the term before.
And we will target content to users based on country,
we'll base, do it based on campus,
we'll do it based on building.
Pretty soon, we're going to base it on org,
and so that way the corporate news team can reach
the people that they want to reach with
the news that is relevant to them.
So, the silly but true example is, hey,
there's going to be a blood mobile outside of
building 21 today and they can target
that news to show up only for people
in the general vicinity of building 21.
And for those who are in Norway who don't care about
the blood mobile outside of building 21,
they can show them a different,
more relevant piece of content.
And i'll just plug here the way we do that is
through the new Bulk Import API.
So last year, David?
>> Is when we.
>> I can't remember,
but we rolled out the new
Bulk Import API which makes it a lot easier
to pump custom user attributes up into the cloud.
So really, if you think about your profile
so it's comprised of three pieces.
The stuff that we suck information
as your acting directory.
The stuff that the user supplies on their Delve page,
their Delve profile page,
but the third one is
this combination of authoritative data that
we in IT own and push
up into the profile store direct to make available.
So, I guess my point
there being that anyone in the audience could do the
same and fill out that profile store
with things that are relevant to their business.
>> Yeah, then you can use that information
to target your content to people.
>> Exactly. Exactly.
>> All right. So, here's
a couple of questions that came in that are very,
very similar and I'll put them together into one.
How long did it take for us to move to the cloud and
at what rate were we able to move to the cloud?
>> It's kind of funny as we think about this now
in retrospect as we started
>> It comes up in every webinar.
>> I know, but we started to move what?
2011 was when we started the,
we said November 2011 we're going to go all in,
we're going to get the cloud,
we're going to do a bunch of work.
We did a bunch of pilots and we did,
we started moving things.
I mean, so for us like how long it took?
It's not really a comparable amount because
we did this over a number of what?
Almost four years to get
I'd say to 99 percent really in the cloud.
>> And in the beginning it was through a cocktail straw.
>> Right. Exactly.
>> And in the end we had a pipe.
>> But I think to your point Jim was when we
did it we didn't have the wealth of
options there that are available to us today.
>> Express Route didn't exist.
>> Express Route didn't exist.
The third party tools didn't exist.
We just released a new free content
migration tool, at Ignite it was announced.
So all these things that
we had to invent are now available,
so I think any real world customer
would have a much faster, easier experience.
>> Not to mention the fact that when you think
about this, you're planning the,
a big part of this
is also segmenting your migration and say,
what am I going to start Net new?
Where am I going to say, go create a new site?
So everyone wants to create new experience,
go create it in the cloud, stop creating it Onprem.
It's kind of the first thing, open the door effectively.
>> Right.
>> Then, say, okay now I'll open the door,
what do we need to lift and shift effectively?
We did that and lots of migrations to that.
And then getting into a more custom experiences,
and say you know what?
I've got this MS web as Sam said this custom portal,
and I got web parts on this portal,
and I've got a bunch of custom solutions on this portal.
How do I re-factor the UI,
the information architecture, move,
migrate the content and re-factor solutions to it?
Then of course, there's the biggest,
heaviest part of the lifting from
the complete refactoring perspective,
but it's also a thing that can go near the end.
And so when we think about migration,
if I were to do it again now,
if we were kind of Onprem,
I kind of still segmented in those areas,
but I wouldn't worry as much about the sites that
don't have to go too quickly because of hybrid,
because I've got the opportunity to
say I can still keep your experiences Onprem.
We're not in a rush to retire the rest of our Onprem.
We will, but now what
we're down to this level it's like, why rush?
>> And I guess the last thing I'll drop in there is,
I was talking to an external enterprise customer
just last month actually,
they're planning on moving 75 terabytes
of content to the cloud,
and working with our consulting folks,
it's not a plug for them just mentioning that they
were involved in the project.
Right now, they're seeing that
as a 9 to 12 month project.
So if the thrust of the question is,
can I get a gauge on how fast they can do it?
I do know one enterprise customer that's
going to try to about 75 terabytes in less than a year.
So, if you are organized and go in with a good plan,
you can move a lot of content really quickly.
>> Darren, we are planning migrations now?
>> We have divisions that
we've acquired that we're trying to move in.
>> Yeah, that's right. We, I
mean now I guess it's public news, we acquired LinkedIn.
And LinkedIn has a lot of data
previously and
a couple different competitive environments.
So we are in the process of migrating that data.
Some of the challenges there is that
LinkedIn would prefer to have
the process largely transparent,
or silent as we call it.
So, no moving data
and interrupting the usual workflow over there.
So those are some of the challenges we're facing.
And there's about 13,000
employees there that we're going to be moving soon.
And then of course, there will be
the multi Geo where we're going to
start dispersing the content for
people that are in Asia and Europe,
moving that eventually over to those respective Geos.
So we've got a fair bit of migration
going on, but as Sam said,
four or five years ago this would have been a lot more
difficult because we would have had a lot less tools.
Now, we even have the migration API
which we didn't have back then.
Back in our day,
we had the standard CSOM and we liked it.
>> But now we've got the migration API
which in some cases,
depending on the tool, can be up to 30 times faster.
So, it is allowing us
to move a lot more data a lot quicker,
and because that API is a lot more geared
towards the types of challenges we faced in migration,
we're also seeing a lot less errors and
incompatibilities and collisions and
things like that. So.
>> One of the key points, just to note,
is that when we started with what,
38 terabytes of content roughly.
>> Pretty close to that.
>> And we're now what, two,
almost two petabytes of content in cloud.
>> I think we just crossed two petabytes, yeah.
>> Between OneDrive for Business and SharePoint.
I mean, the adoption of a cloud service
has been far more than migration.
I think if you look at it in hindsight you'ed say,
content came from out of
the woodwork into these services because people,
they just jumped in.
It's like, wow, now I can work anywhere I need to.
I can, we don't want the content in my machine anymore.
I want to be a finding that machine.
Jim's machine breaks who cares.
I've contents in the cloud anyways.
So, I think that's the change in
dynamic and so we've got this
massive volume that we're now managing.
So when I think on migration, I go well,
yes that was important,
but was really that we must start fresh on
the new stuff that made a bigger impact to our,
I guess, footprint that we have now.
>> Well, as I look at
the corporate landscape my main thing about always,
even I didn't realize how big it was,
that sounds arrogant, I mean.
But I didn't realize at the time how big it was
going to be because we retired massive file sharing.
We retired discs connected to servers under desks.
We, all this content that used to
be number one uncrawled, unmanaged,
no lifecycle, no e-discovery,
because we made easy for number one,
for people to have a place to store it.
And number two that,
let's not underestimate the impact
of anywhere access on any device.
>> Just take a look at
the typical laptop in our enterprise.
The C drive usage,
the main drive is minuscule
now as opposed to before
when we had all of our documents,
all of our stuff on the directories on our C drive.
Now it's all in
OneDrive for Business, and it's a good thing.
>> And I would take it even a step, one more step.
The reliability of the sync client,
such that our users now believe in it.
I don't know if anyone in
the real world out there had users that
had sync client trouble with
the old OneDrive for Business client which was.
When it worked it was great. Occasionally it would trip.
The new robustness, the speed,
performance reliability of the new tool is such that
our users now are really making bets on it.
And in fact they're, I know we announced it at Ignite,
where you can as an IT person,
automatically redirect a user's
default folders to OneDrive for Business.
So, pretty soon you'll be
able to have that in place as well.
So you're automatically redirecting
those users to the cloud.
>> Plus now with OneDrive for Business,
sync client dealing with bigger and
not just OneDrive, whole SharePoint stuff,
I can have placeholders effectively on
my machine for documents I care about,
and watch the sites I can
sync the piece of site that I care about,
and use and knows what to bring down and
get the volume up and the cloud might be enormous,
far bigger than my hard drive.
And so, I'm just bringing
down the pieces that matter to me,
and I think that's a big shift to
why people are moving more off the machine.
>> If I were to add one thing in the discovery of
the information discovery is much
for richer with the cloud story.
Because if you now know your content is in
the cloud which means it's discoverable through Outlook,
through Bing for business,
through your Windows search box,
through your SharePoint sites and everything, right?
And it's such an amazing story
that you don't have to know where to start.
You can almost start anywhere
and still find your content.
>> Okay. Well, thanks everybody.
We're almost at the end of the hour.
So before we go,
I'd like to ask each of the experts
a final key takeaway that they would
like for the audience members to leave with.
Let's start with David.
>> So one thing I think about is,
when I'm talking to customers internally about building
their modern sites or their sites is,
we think about solution ads,
build them this modern from the get go.
Even if you're building on a classic site,
site collection or publishing or classic features,
if you're building a new customizations, new solutions,
plan the modernization upfront,
build the machine from framework parts so they can
be moved to a modern experience. Whenever the time comes.
>> All right, my takeaway
revolves mostly around some of
the new stuff that we're working with,
the Power Apps, Flow,
Office Graph API is starting to get
more and more robust as the days go by.
Automation has made things so much easier.
I don't care what anybody says,
automation doesn't make you lazy, it makes you efficient.
So definitely start getting into Flow, Power Apps,
constantly review the graph API Because there's
always new exciting things coming
in there and ways to automate it.
With PowerShell, we've got
PowerShell modules now for things like retention,
allowing us to automate some of
our retention workflows that are coming out.
How we PowerShell for things like SharePoint.
Themes is also getting PowerShell soon.
So really if you haven't yet gotten
on the PowerShell bandwagon there's no better time.
I mean especially now that PowerShell is
available for Mac, Windows and Linux.
So no matter what operating system
you have out there, there's automation waiting.
>> Thank you.
>> Soujanya.
>> I think my one key takeaway
in the search space specifically,
is that I think search is just a piece of the puzzle,
and the puzzle is not complete unless
there's strong content publishing,
content creation,
permissioning, and all of those things, right?
We need to have
strong calls and all of
these areas for us to have a great search experience,
and if one of those pieces is broken,
then your search experience lacks and you will have
people dissatisfied with the experience.
>> Alright.
>> Sam you're last.
>> That's dangerous.
So I would say,
I would encourage everyone now in the audience to
go in and start looking at you know
what their plans will be for adopting
the new site types and as well
as the new tools at our disposal.
For example, you can go out and
there's a custom theme generator already available.
You start generating your own custom themes for
your own enterprise to be
used in branding your sites today,
to be able to brand your hub sites tomorrow.
So this is available today.
I'll just put a plug in for ignite.microsoft.com.
Lots of sessions on everything we've talked about today.
You know the new search stuff, the hub sites,
the design templates, everything.
So, I would encourage you to
go look at ignite.microsoft.com.
>> Thanks Sam. I want to
take a moment to thank everybody here for taking
time out of their their day to
join us and share their expertise.
I'd also like to thank you
the audience for joining us today.
I hope you found the session valuable.
So the On-Demand version of this session will be
posted to microsoft.com/itshowcase soon.
Don't type the 'soon.'
You can find the additional IT showcase content
like business and technical case studies,
productivity guides,
videos and upcoming webinars on the
microsoft.com/ITShowcase site as well.
So please join us for future webinars,
and please bring your colleagues with you.
Thank you very much.
Không có nhận xét nào:
Đăng nhận xét