SharePoint getting lost in the Cloud?

My experience is that though most Office 365 users include SharePoint (sites) in their tenant, the real use is coming from Exchange Online, Office ProPlus, and OneDrive.

Most people seems to think OneDrive settles the document storage needs.

They are wrong in a number of ways.

The most obvious problem is a OneDrive is that when you lose a staff, and end their license, all their documents go with them.

What you need is a central place to put key documents and lists that you company needs beyond a single users.  These documents you might want version controlled, assigned with metadata, and searchable.

What you want is Sites which is SharePoint in Office 356. Better yet SharePoint with Delve, allowing your users to see the socially most significant documents in circulation.

Planning a proper Sites configuration is not technically hard but it is a lot of work to create a good Information Architecture, that is a plan of sites and subsets.

Here are some simple rules:

1. Regardless of what anyone says the hard limit for supported Sites is 200 GB.  So if you have a lot of content to store make many sites.
2. Don't rely on your company structure to provide the structure for the sites, rather find out what people need or let teams design they own layout.
3. Keep it clean and simple, don't worry too much about colours or new layouts.  Spend effort on design of layout and making it easy to use over making it look a certain way.
4. Use Wikis, they are easy light weight way to store data.
5. Keep pushing users to it, if they have a question don't write an answer when a link in a wiki exists, have the search for it in the wiki.  Get users to learn the independent way of looking for things, break the ask first habit.
6. Have people who have keeping SharePoint up to date and clean as part of their jobs.
7. Find energetic people who want to work with Sharepoint.

Identity: Cloud for Sync vs AD FS

Lots of people using Office 356 seem to assume they just need AD FS.

What AD FS gives you primarily is Single Sign On, this also enables you to connect your Office 365 to a number of other Cloud services provided by Microsoft like CRM and Azure.

But there is a cost of AD FS.  To get this benefit you need to to build a 5 server farm, with load balancers.

This servers farm will create a number of single points of failure: load balancers, firewalls, web servers (2) of them and AD FS servers (2).  You need to create and manage these servers.

Now if you use simple sync, using AADS or AADC or what ever it will be when you read this, you need only one server and all it does is updates identities from AD, including sending a HASH or a HASH of the password.

So what it the difference for users.  Users in the worst case without AD FS 2 you users log in to their computer, they then open the web page and log in again with the same credentials.  The worst case is that they need to login twice.  Normally users just save their passwords so they only need to enter it when they change browsers or machines, or when their password changes.

From a user perspective you get maybe 10 re-entries of a password THEY MUST KNOW to get on their computer in the first place.  With Federation you get rid of those 10 actions a year, actions the staff will know in every case how to manage, at the cost of a single point of failure and 5 boxes and 2 load balances.

Frankly its hard to make the case.

If management demands SSO I would suggest you go over the facts above, point out that servers like Twitter, Facebook, Hotmail, Gmail, Instagram, and Snap Chat work across devices without Single Sing On.

You will save money and effort by treating Office 365 as what it is, a Cloud tool

Web 1 to Web 2 to Web 3

Understanding the Difference Between Microsoft Azure & Amazon AWS | Plur...

SharePoint 2013: Getting Started (Tutorial)

PowerShell Commands in SharePoint | Bestdotnettraining

Exam Prep: 70-331 and 70-332 - MCSE: SharePoint (Microsoft SharePoint Se...

Value of Adding a domain to Office 365 (way more than you might think)

Adding a domain name to your Office 365 is a key part to making your People Centric Enterprise work.  Its pretty simple to do, but it will give your firm a unified email domain while still working with Office in the Cloud.  No more having to either maintain a an on-site Exchange Server or have to give people a gmail or hotmail address for your business.


Its technically easy to do, as the video shows, but its worth thinking about how this all fits in the new People Centric Enterprise.

Your domain name is more than just a company name, it should be a brand, a personality and identity that reflects something about what you want to tell the world.  By being able to assign all your users names with your domain, the same domain as your web page, you create a Cloud based identity.  Users can see that your web page, your Office 365 and your email and Lync are all part of a single surface that they can contact from any device anywhere.

Having a single domain that for the web site and the internal messaging and collaboration builds a sense of unified working, where the people are not being made to fit in to boxes.  Rather your domain becomes a large tent where your workers, your partners and your customers can find ways to communicate, learn and share around your business.

Ravello looks amazing

This the demo but can the cloud really be this easy?  I am registering for a demo and will see.

The world of a SharePoint professional is about to change

SharePoint IT generally involved a great deal of infrastructure and server specification, build and test. This can be very time consuming, and it was my experience that from the first requirements gathering to build would often take months. My own way of working was to create a virtual machine of SharePoint and work with the client early on, to provide Agile designing.

 But over time this caused its own problems. My virtual machines would generally not use AD, they would have a express database, and I would use the some server admin account to run all of the Server Accounts, making for a less than robust account. So over time I would use a better VM provided with AD, DNS, and SQL, but this itself became something of a project. I could copy the boxes over but to build them in client environments was not a full dev box task. From an initial requirements gathering to a running system kept taking months.

 The best way was to get a company that already had SharePoint and then start doing the requirements gathering, but this meant that the organization had to commit to SharePoint before really knowing what the use case would be, not very likely. Office 365 solves these problems nicely. You can get the client a demo site with 25 to 250 users in a matter of hours or days at the most and be working in a preparation project in the first week. But this does not mean that technical skills are not longer needed, its just that they are moving more to things like connectivity, sync, app development, security and identity management.

 That is why I have included the video above, it is part of one of the new skills every SharePoint IT pro needs now, creating AD FS integration between existing legacy AD on-prom and Azure AD running your SharePoint 2013. Even if you never do this in your job you need to fully understand what is involved and the risks involved. Previously AD was just there, you worked with what you had as a SharePoint expert. But today you need to be more aware of how AD works, and the problems of integrating existing ADs, and all their potential problems, in to the Cloud.

Office 365 and Domains

n our personal life most of us are more than happy to have email accounts that end in googlemail.com or hotmail.co.uk or apple.com. It actually makes it easier for people to find us, they need to only learn our prefix. The problem is few of us have our names as googlemail accounts, we end up using cute phrases or putting numbers at the end of our names.

 When you get an Office 365 account you get a domain inside of the onmicrosoft.com domains. 

This means if you register something like loveworks as your company name you will get emails and logins that end loveworks.onmicrosfot.com and your emails will be of the form <username>@loveworks.onmicrosoft.com.


Again for a smaller company this might be fine, but for a larger firm or a firm with more established presence on the web you might want to use an existing domain, or register a new domain so your users can got to a URL like loverorks.com rather than loveworks.onmicrosoft.com. This is probably a minimal step for users who are moving to Office 365 and here is the easiest clearest video I have found to do this:

Now say you are an even more mature company with an existing Active Directory on premise and lots of applications running using your Active Directory. You still want to use Office 365 for mail, messaging and collaboration but you want to keep your existing Active Directory and manage your identities on AD. This makes things much more complex. You can sync your identities between the on-prem and Office 365.

I will cover steps to do this in later blog posts.

For now let me say this is something you really need to think about.  If you can live with a separate AD in the cloud and your users have two logins and two passwords to remember its probably best to live with it.  By synching your on-prem AD to Azure AD used by Office 365 you are inviting a lot of work.  If you only have less than 100 employees, or a lot of contract workers who never get in your AD, or no onsite AD then its best to keep everything in the Cloud.

Sync can be great and this is an amazing features of Microsoft, but its worth thinking that millions of people have email addresses in the cloud that they use everyday, without worrying about online sync.  It might be good to start thinking Cloud-First, keeping things off premise as much as possible.