blog.frederique.harmsze.nl my world of work and user experiences

September 30, 2019

Some tips for respecting the privacy regulations in project sites

Filed under: Governance,SharePoint — Tags: , — frederique @ 22:36

Recently, I have been talking about GDPR in the context of SharePoint project sites for a construction company building houses. What practical design choices should we make for the new SharePoint template we are developing, combined with instructions to our users? Let us take a look at five of them.

In a previous post we talked about the Office 365 security and compliance GDPR dashboard, that can help us detect and manage sensitive information after it has been stored in our Office 365 tenant. But it is better to think beforehand and aim for privacy by design. We should only store and process personal data if we have a clear purpose for it. And only for the people who do need these data, for as long as they need it.

1.Don’t use personal data if you can keep it abstract

In their building projects, the houses are bought by real people, who have real personal data. In the project site, information has to be shared about the construction of the individual houses: which kitchen options should be included, what work remains to be done for that house, et cetera. However, there is no need to refer to these houses by the names of the buyers.

So we don’t list a house as the one bought by Mr and Mrs Smith, but at the house with building number 32. And we explain to all users that we avoid using personal data unless it is absolutely necessary to get the job done and we can justify sharing these personal data.

2.Put documents with personal data in a clearly marked, separate, secured library

We do have some cases where some project team members do need to see personal data in order to do their jobs, like commercial team members who need to talk to the house owners and renovation architects who need to see photos of the original rooms the may display personal belongings.

So we have a separate document library for the house owner documents, which is clearly marked as such. That library is listed in the site menu under the heading ‘Sensitive’. And only the project team members who need to use these data have permission to enter the library. We explain to our users where they have to store and find these documents, and that if they don’t see the library, they do not have permission to open it.

3.Only share the personal details that are needed, nothing else

We have a secured list of the contact details of the owners of the houses that are being built, so that project members who need to get in touch with these people know how to reach them. In the past, that list also included fields to share information about the spouses, children, hobbies, et cetera. Somebody got inspired by customer relationship management and got carried away… That information is quite irrelevant for the construction job.

So we trimmed down the list in our site template, to contain only the fields relevant for the job. This way, our users understand that they should not include other personal data.

4.Only allow individuals to access personal data. Not AD-groups

In parts of their project sites, all employees in the business unit or even all employees in the company can see the information. For example, the basic project information is visible to all, for transparency in the organization. For these “high visibility” lists and libraries, access is managed by way of AD-groups that include everyone in that unit. However, you cannot easily see who is part of that “everyone group”.

So in lists and libraries that contain personal data, we do not allow security by way of AD groups. We tell the site owners that they have to add individual users to the SharePoint permission groups, to explicitly and purposefully give those people access.

5.Delete personal data no longer needed after the project

After the building project is finished, some personal data may be needed by the aftercare people. But we should not keep personal data just in case somebody may be interested in them someday…

So we remove the permissions on the personal data for the users who are no longer involved in the finished. And we delete the personal data that do not have to be kept for a clear purpose. For example, we need to keep the data of the companies involved as subcontractors, but we do not need the phone numbers of the individual people. So we keep a companies list for the project relations, but not the people contacts lists.

 

All in all, we are baking some privacy measures into our SharePoint template for construction projects. We are giving the site owners and end users specific instructions. And we are creating awareness, that we need to be careful with personal data.

August 31, 2019

Careful with Modern SharePoint on old browsers and Windows

Filed under: Digital Workplace,SharePoint — Tags: — frederique @ 23:14

At the client where I am working at the moment, most users have Windows 7 and the standard browser still is Internet Explorer 11. We are starting with the Modern experience of SharePoint Online, And that is not a good combination.

The Modern experience of SharePoint is quite powerful. For example, our users are clamouring for the functionality to download multiple files in one go. In the Modern interface, the Download button does work like that; in the Classic experience it does not. But Modern SharePoint does not work smoothly in Windows 7 in any browser and works badly with Internet Explorer 11 (IE11).

So what can we do from IT?

Keep up to date

Of course the key thing is to provide users with a modern version of Windows, in this case replacing the antiquated Windows 7 with Windows 10. We all need to upgrade anyway, because Micosoft announced Windows 7 support will end on January 14, 2020.

This obviously is not easy in a large company with many legacy applications. But we can no longer get away with leaving a fossil Windows version on everyone’s computers…

Allow a browser that does work

Internet Explorer 11 is terrible with Modern SharePoint, as well as many modern websites You cannot get Edge on Windows 7. So you have to allow users to use another browser, like Chrome or Firefox.

Even if you insist that the official standard browser is the old school Internet Explorer 11, make sure you have a consistent story for the alternative: which browser should they use, in which situations. Especially if the company has doubts about the security of a browser like Chrome. Ok, then tell us what we should use.

Plan the roll-out of Modern SharePoint carefully

Don’t push the Modern experience of SharePoint while the users are still on Windows 7 and Internet Explorer if you don’t have to. If they are already using SharePoint in the classic mode, keep it until Windows 10 and a modern browser has been rolled out.

For example, we are currently updating a project site template for one of our units. Our key users were very clear on it: we keep it classic. They have many innocent users, who won’t be able to handle the bad experience with the Modern version on the old computers. We will transition to Modern some time next year, when everyone has Windows 10 and a reasonable browser…

What can the end-users do?

Switch to a different browser when IE11 does not work

As long as you don’t need support from somebody who adheres to the official story of Internet Explorer as the standard browser, switch another browser (like Chrome of Firefox) for some tasks. In particular, editing site pages in a Communication site.

Switch to the classic view when the modern does not work

In document libraries and lists, you can switch back to the classic view if the modern gets stuck. The views tend to be “sticky” when you expand a group for example. This trick is useful for people who have worked with the classic SharePoint and who don’t mind experimenting with views. I know I use it from time to time..

Link to return to classic SharePoint from a modern library

Link to return to classic SharePoint from a modern library

Enter metadata via ’i’ > ‘Edit all’

In classic SharePoint, conscientious user uploading a document filled in their metadata in a dialog box presented automatically as step 2 of the upload. In modern SharePoint, the user no longer gets prompted to fill in the metadata in such a dialog screen. Even if some fields are required, the uploaded document just lands in the library, The fields that are required are marked with an orange ‘Required info’ label though.

You then need to select the document and click on the I-icon to set the metadata. In the pane that opens on the right hand side of the screen, you can enter the metadata directly. However, the fields in these panes are “sticky”. Sometimes, the value you enter does not get saved… If you want to enter several fields, it works more robustly if you click ‘Edit all’.

To enter metadata, select a document and click the i in the top right corner. To make sure the metadata are properly saved, click Edit all.

To enter metadata, select a document and click the i in the top right corner. To make sure the metadata are properly saved, click Edit all.

 

March 31, 2019

Saving overweight views in SharePoint

Filed under: SharePoint — Tags: , — frederique @ 19:30

SharePoint Online cannot handle views involving more than 5 000 items, especially in Classic mode. Even if it does not have to display them all on the same screen. The view collapses under its own weight, unless you limit the number of items by filtering it down using indexed columns. And when the view does break, the end-users do not see any information and freak out. Ok, this is not new. But we still bump into this issue, so let me discuss it in this post.

I am not the first line of support for end-users, but I do speak to people in the business and they do know how to find me when they experience difficulties in Office 365. Recently, I spoke with a few people in the business, who thought that their document libraries had broken down irrevocably and who started to doubt the entire concept of their SharePoint site. Oh dear… The users got a message telling them that the view they were looking at exceeded the list view threshold of 5.000 items. And they interpreted this message as follows: our document library breaks when we put more than 5 000 items in it. But we have far more documents, so this is not working at all.. Help!!

Overweight view in the Classic experience

Overweight view in the Classic experience

Overweight view in the Modern experience

Overweight view in the Modern experience

These users have libraries with over 5 000 items, which are structured with document sets (so yes, they are still using the Classic experience). However, some of their most important views ignore the document sets. For example, one of the views displays the key documents from each set, which they need to list as input for some subcontractors. The key question for me was:
Do you want your view to display more than 5 000 items?
Or are you trying to distill a much shorter summary from a large library?

Fortunately, the desired view was much shorter than 5 000 items, so we only had to configure the view properly.

The following tricks helped us to slim down overweight views and get them to work for our end-users:

  • Use a filter to narrow down the number of items, instead of the item limit.
    Setting the item limit does not help. If you set the view to display, for example, 30 items at the time or display only 30 items, SharePoint still tries to get all of the items in one go, before displaying the first batch.
  • Filter by indexed columns.
    Filtering by columns that have not been indexed does not help either. You need an indexed column: List settings > Columns: Indexed columns. For example, if the column Created has been indexed, you can create a working ‘Recent’ view by not only sorting by Created but additionally filtering Created is larger than [Today] – 365 (or a smaller number, if too many items were created this year). See Add an index to a SharePoint column.

    Recent items, filtered to display only items created this year, with the newest items displayed at the top.

    Recent items, filtered to display only items created this year, with the newest items displayed at the top.

    • Use a simple index, by one column only. A compound index including a secondary column does not help.
    • You should set up the indexed columns while the list or library still has under 5 000 items.
      In the early days of SharePoint Online, you were stuck if you had not indexed your filter columns before the list grew beyond 5000 items. These days, SharePoint Online is smarter, although you will still experience less problems if you set up the indices beforehand.
    • SharePoint Online starts to index a column automatically when you create a view sorting or filtering by that column. For example, if you create a ‘Recent’ view sorted by Created date, that column gets indexed automatically.
      This only works if the list settings don’t block it. Stick to the default setting: List settings > Advanced settings > Allow automatic management of indices? = Yes.
      And this only works if the list still has less than 20 000 items. So again, it pays to be proactive about these large lists.
    • You can still index a column manually too, even after the list has become overweight. In my experience, it may take some time for that index to actually appear. Lists that are only slightly overweight can create an index within minutes, but it hasn’t always been that quick.

      Indexed columns: Created has been indexed automatically, The others have been indexed manually, after the list became larger than the threshold of 5 000 items

      Indexed columns: Created has been indexed automatically, The others have been indexed manually, after the list became larger than the threshold of 5 000 items

  • If you filter by one column AND another column, the first one should already bring the number of items down to under 5 000. You may think that an AND filter is symmetrical, but it is important to put the right filter in first. For example, if there are many final documents but not too many key documents, filter your view ‘Final key documents’ as Key documents = Yes AND Status = Final, and not the other way around.

    Filter by indexed columns: first by the one that restricts the number of items the most: Key document = Yes, And then refining it by Status= Final to achieve the desired view.

    Filter by indexed columns: first by the one that restricts the number of items the most: Key document = Yes.
    And then refining it by Status= Final to achieve the desired view.

  • Filtering by one column OR another column breaks the view. So don’t filter a view ‘My Documents’ as Modified by [Me]  OR Created by [Me], even if there are only a few documents created or modified by each user.
  • Is the view still broken? Try to make the view less complex (see Manage large lists and libraries in SharePoint)
    • Sort by only one column.
    • Don’t sort by  “difficult” columns (people, lookup or managed metadata).
    • Don’t group.
    • Don’t use totals (which currently don’t work in the Modern view anyway).
    • Don’t display more than 12 of those “difficult” columns.

Views in the Modern mode of SharePoint are more robust, but they still have their limitations. In the Modern experience, I have seen views with over 7 000 items that worked just fine. But the view with over 70 000 items still broke; 20 000 seems to be the new 5 000. And the Modern ‘All items’ view of my test list of just over 5 000 item is still broken too; maybe I have to wait a bit longer for the view to get its act together and start working…

All in all, large views still need attention, but we do have some tricks to help our end-users.

November 30, 2018

Getting our users on board in the migration to SharePoint Online – a checklist

Filed under: SharePoint — Tags: — frederique @ 23:56

I am involved in a migration project, to move thousands of sites from SharePoint 2007 to SharePoint Online. There is the technical aspect to it, but I am mostly concerned in how we can get our users on board. Give them the benefits of the upgrade to new tools that meet their needs better, whilst mitigating the hassle of the actual migration and change.

I have talked about the question what you should migrate, in what form and in which order in a previous post. Now here’s an annotated version of the 15 point checklist I use in the actual migrations.

1.Determine the migration scenario

Do you want to migrate the sites as they were, or only the content? To what template? With what mapping of the metadata? And what about the permissions? We have different scenarios for different situations. For example, archive sites, project sites and department sites for different business units, which have different source templates and different needs.

2.Test the results of the migration factory

Once you have the scenario, test it in a trial migration of a representative set of sites before you ask the business users to test anything. We have seen some unexpected results in early attempts, so we have learned to invest the time in these tests, to make sure the business users don’t trip over these problems. We keep track of all the sites and their migration status and the issues in SharePoint lists.

3.Involve the key users

Talk to the business about their needs, what do they think is still relevant from the old sites, what do they want with the new sites. And ask some key users to check the sites you migrated, after you have weeded out the errors.

4.Plan the final migration of live sites outside office hours

You need a content freeze for the migration. No problem for archive sites, because nobody is actively using them. But for active sites, you need to minimize the time users cannot work in these sites. Our solution is to migrate the bulk of the content while they work, and then do an incremental migration to update the content over a weekend. Plan the migration weekend with the business, to try and suit their calendars.

5.Communicate beforehand what will happen

Some people take any changes in their stride, but others really want know beforehand what will happen. So make sure all users are aware of the upcoming migration. Communicate, for example via the intranet and/or email:

  • Which sites will be migrated (for example, project sites or department sites) and to which environment they will be migrated. Hopefully they have already heard something about the new environment, like the rollout of Office 365 with SharePoint Online and you can refer to that.
  • What do they have to do. For example, stop using the old sites Friday before 18:00, park files locally if they have to work during the migration weekend, on Monday reconnect their Outlook plug-in to the new address, and check if all of their content was moved over correctly.
  • How are you going to help them. For example, provide them with a user manual, an email address and phone number they can contact, and in-house support on the day after the migration.
  • Who they can contact if they have questions now or later. If you send the message by email, send it from the mailbox they can contact.

Also, make sure you tell the key users, secretaries and other influencers what will happen, so that they can answer any questions their colleagues may ask them and prod them in the right direction.

6.Check which sites need special attention

We are migrating department sites at the end of the year. So the Finance people started to panic, because this is their busiest time and they do not want anything to interrupt their work. We reassured them that the old sites remain available in read-only mode; they can always still find the information there. And we take extra care when we migrate their sites. We also pay special attention to sites that have a lot of traffic, like sites that are included in the main navigation of the intranet.

  • Test if the content has been migrated properly. We cannot test every single site that is migrated, but we make sure to test these high priority sites.
  • Check the permissions: can they all still read and contribute the same as in the old site?
  • Are the start page, the site menu and the views in the lists and libraries correct and clear? We migrate from an on-premises environment that can handle view of over 5000 items to an online environment where such views may break.

7.Fix the glitches like overweight views

We migrate from an on-premises environment that can handle view of over 5000 items to an online environment where such views may break. So when we migrate large sites, we have some views that give an error instead of a list of items or documents, sometimes even default views, This would freak out the users, so we make sure we fix those views with filters based on indexed columns. Fortunately, we can do this before the migration weekend, once the bulk migration has been performed – because we already indexed the relevant columns via the site template.

8.Arrange for the update of links to the migrated sites

In this round, we are migrating some department sites that are connected to their intranet via static hyperlinks. In a previous round, we migrated project sites that were linked to CRM. These links need to be updated. We do not own that intranet or the CRM environment, but we do not want our users to hit dead links. So we asked around and found the managers of those systems who could update the links.

9.Provide an entry point to the new sites

The users have to know where they can find and access their new ‘digital homes’. We have done that in different ways.

  • When we had reliable list of owners for each site, and owners we could trust to inform their members, we sent the owners a mail with their URL (using a mail merge on our list of sites and owners). However, in most cases our governance failed in the past, and we don’t have a reliable site owner.
  • For the migration of a large number of project sites, we told the users to access their new sites from CRM, because that already was their preferred entry point and we could update the site links in CRM.
  • For another migration, we pointed the users to a site overview page with a search option where they could find their site. And we gave them the tip to Follow that site when they have found the new address.

10.Offer help materials

Our users need to take some actions after the migration, like reconnecting their Outlook plug-in to the migrated sites. You need to give them instructions on how to do that. Also, they have to learn how to use the new SharePoint Online environment. Most of it is intuitive enough, but not everything and now for everyone. So you need to give them a user manual and tips on that.

Offer them a single point of entry for all of these help materials. If you use a SharePoint site for this, you can update the information as you experience the migration and hear the questions that can come up. But be aware that some users will print put all of the materials as soon as you send them the link, so make that first version a serious one.

11.Send a message before the migration starts

If you have published a message on the intranet about the start of your migration, you cannot assume that everyone has seen it. So send an email Friday afternoon. Make it short and to the point, and put the key message in the Email subject: stop working in your department site before 18:00.

12.Run a script to compare the number of items in the old and the new sites

After the incremental migration to update the latest additions and changes in the migrated sites, the number of items in the source and the target should be the same. Unless the users have deleted files from the source file and the incremental migration cannot take that into account.

We had a script to compare the number of items automatically, and at the end of the migration weekend is the time to run it. In one round of migrations we forgot to run the script at that time and only ran it after the first day the migrated sites had gone live. But by then there were many discrepancies, especially when users got enthusiastic about the new options…

13.Make sure the old sites are locked after the migration

After the final migration to the new sites, users should not add or edit anything on the old sites anymore. Yes, this is obvious. But no, this does not always turn out well. We have had a glitch in the script, so that people were still able to work in the old sites. And of course these people had not paid attention to the communication.

So you need to double check that these sites are locked down in read-only mode, to allow the users to check the migration but force them to move to the migrated sites.

14.Send a message after it has finished

After you have finished the migration, make it perfectly clear to the users that they have to switch to their newly migrated site now, where they can find it, what they have to do now, and where they can find help. Put in on the intranet, send an email, tell all the key users and secretaries. This is not the time to be stingy with your communication.

15.Arrange for support on the day after the migration

There are always some issues or at least questions after a migration: where is my site, I’ve lost some documents, how do I connect the new site to my Outlook plug-in, … Try to be at their offices, to give them personal attention. Pay attention to the details when you arrange it, especially if “strangers” are to help out in this matter: who should be where and when, who is the host at that location and what are their contact details.

 

This weekend we are migrating the department sites of one of our more prolific business units. And yes, we use the checklist, specified for the migration at hand. In OneNote, with checkboxes to indicate what we have already completed. Check.

July 31, 2018

Some notes on the migration of SharePoint sites

Filed under: SharePoint — Tags: — frederique @ 23:11

Currently, I am involved in a project to move a large organization into the cloud of Office 365. That includes the transition from SharePoint 2007, 2010 and 2013 to SharePoint Online. Very useful, but quite challenging, because of the number of sites, unclear ownership and the complexity of the original environment. So let me give some tips, based on our experiences.

Only migrate what is still relevant

To save migration effort and to prevent the innocent user from getting swamped in obsolete information, you should try to exclude information that is no longer relevant.

This is tricky, because most content owners have a knee-jerk reaction when you ask them what can be  deleted: “nothing can be left behind”. But you may still get rid of some things. This is most important when it comes to items that are hard to migrate: it is really worth the effort to do this?

Determine which sites we can ignore

In this organization, we have not been able to pinpoint any “real” sites that we can just leave behind. They have many long running projects, most of the old information needs to be stored at least ten years and usually longer, and they don’t like to delete anything. However, we also have sites are not “real”.

So, we can still ignore quite a few test sites, demo sites and training sites that showcase the old functionality but won’t mean anything after the migration to SharePoint Online.

Determine which lists and libraries we can ignore

Within the team sites, there are some lists that we can ignore. For example, as they now manage the contacts in CRM, the contact information stored in the SharePoint sites is obsolete.

So the technical guys doing the migration, excluded these lists from the migration scripts. And they were happy to do so, because these lists had some weird customizations that them caused problems.

Determine which fields can we can ignore

The libraries had some fields with very strange content, like ID-codes that do not make any sense to ordinary users. As it turned out, some those were left-overs from the previous migration, from Lotus Notes to SharePoint 2007. Other fields we encountered were part of a very old version of the site template and no longer used by anyone.

So we left these obsolete fields out of the new templates and out of the property mappings.

Archive what you can, only migrate as ‘active’ what you must

We have to keep a lot of information from projects that have already finished. The **

Determine which sites are still active and which are inactive

We based our status labels on existing lists of project (for example in CRM), last modified dates and information from the business. We have some humongous Excel sheets to gather, enrich an manage all of this information. Over the course of our long term project, we have to update this list.

Create a simple archive template

The goal of these archive sites is to allow users to find old information. This implies these sites don’t need to have advanced functionality. No smart lookups, workflows, beautiful image carousels or anything like that.

So we created a very empty site template: a container into which we could migrate the old lists and libraries. The tech guys included in the migration script steps to make sure that no fields are required anymore. And complex lookup fields that have a lot of customization are mapped to basic text only fields. After all, all we want to do is preserve the content, present it in views that help them make sense of that content and allow for searching.

Migrate the archive site at your leisure

The good thing about archive sites, is that nobody adds or edits anything there. So you don’t need to worry about a content freeze for these sites, which makes our lives a lot simpler.

Prioritize

Think where you want to start. For us the key criteria when we plan which sites are moved first are:

  • In which SharePoint does the original site live?
  • How complicated is the target template and migration script for this type of sites?
  • Do we have owners or other stakeholders who we can contact about these sites?
  • Are the new sites needed for another project?

Get rid of SharePoint 2007 first

We want to move out of the severely prehistoric SharePoint 2007 first, before it crumbles completely. After all, SharePoint 2007 has been declared officially “dead” by Microsoft almost a year ago (SharePoint Server 2007 end of support roadmap) https://docs.microsoft.com/nl-nl/office365/enterprise/sharepoint-2007-end-of-support?redirectSourcePath=%252fen-ie%252farticle%252fSharePoint-Server-2007-End-of-Life-Roadmap-ba124775-d5c0-4d68-b88d-8458ad4c3717 And we are experiencing difficulties with storage space on this server,

So we do our best to get as much as possible out of SharePoint 2007 as soon as possible, before we start on the “younger” SharePoint environments.

Start with the simple scenario’s

We did not want to get stuck figuring out all the complications in the beginning. Instead ,we got started with what we could do at that time. This way, we could iron out the kinks of our basic process and migration technology before we start pushing the envelope with the more complex stuff. And we can already lighten the load on the old servers and show the stakeholders some progress before things get more complex.

So we started with the migration of archive sites, rather than active sites. And we started with a set of sites that were relatively homogenous and relatively simple. We are still working up the courage to take on the “swamp” of other sites…

Start with sites that have clear ownership

Unfortunately, we have a lot of sites that have no clear content owner. The site owners in Sharepoint are IT people, not people in the business. Because we have over 8000 sites, we do not want to dive into each individual site, to check who has been active in there recently…

So we started with sites belonging to a business unit that has a mostly complete list of all project sites in CRM, stating the region it belongs to. The secretaries of those regions were able to take charge. They can tell us which sites are still active, which are important and need special attention, and how to deal with sites that turn out to be exceptions. And they could do some testing and give us sign-off on migrated sites.

Align with related project

We are not only transitioning to Office 365, but also to a new version of CRM in Dynamics 365. For one of our business units, CRM and SharePoint were always part of the same way of working. They work from CRM and the information is stored in SharePoint. The CRM project is moving faster than the SharePoint migration.

So we prioritized the migration of the SharePoint sites belonging to this business unit, allowing the Go Live date for the CRM project and the SharePoint project to coincide.

 

All in all, we are still working on the migration to SharePoint Online. But with these tricks, at least we are making progress and we’ll get there eventually.

February 28, 2017

So do we unplug the file shares now?

Filed under: Adoption,SharePoint — frederique @ 23:32

I often see SharePoint environments that exist in parallel to good old file shares. The idea usually is to switch from file shares to SharePoint, because they allow the users to collaborate more effectively and efficiently. However, some users do not want to move away from the file shares. But then again, other users get confused if not everything is moved immediately. I do not have a silver bullet to determine the ideal moment to unplug the file shares. But let us take a look at some considerations, which came up in recent projects.

Switch from file shares to SharePoint

People sometimes ask me why they would stop using files shares and start using SharePoint in one of its incarnations. What’s in it for them? SharePoint sites do offer more functionality for collaborating that file shares. Mosst users can benefit from them, if they adopt them.

And why do I talk about SharePoint sites and not about the newer offerings in Office 365? Because these advantages appear in old school team sites on-premises or new modern team sites in SharePoint online, as well as in the sites associated to Office 365 Groups or Teams. It does not matter, many of the relevant options still live in a version of SharePoint.

SharePoint sites work better than file shares when you need to…

  • Share documents with people outside your organization
    In SharePoint sites, you can only allow externals if the administrators have switched the option on. But I have never had a file share that allowed for external access anyway.
  • Work anytime, anywhere.
    Of course some organizations lock down access without VPN, even in Office 365. But when it lives in SharePoint, your chances are a lot better for accessing information from outside your organization’s network or on a mobile device is a lot easier.
  • Collaborate in a controlled manner
    • Work in a document at the same time with multiple authors
    • Powerful versioning
    • Email notifications when a document is changed
  • Keep track of documents that have more properties than the windows basics
    For example, if documents have an expiry date, owner and a status, you can enrich them with metadata and use those to offer smart views, filtered to display overdue documents owned by my and grouped by status.
  • Work with more than just documents, like action lists, news, links, …
    Classic collaboration entails a lot of documents being exchanged. But the tools allow for more and more different ways to share and keep track of things, especially with the interactive Groups and Teams, including the spiffy Planner.
  • Collaborate on informal notes (for which sites contain a OneNote notebook).

Most of these advantages also apply to OneDrive for Business. OneDrive for Business is the replacement of the personal file share (P-drive or I-Drive or whatever it is called).

Unplug file shares when you switch to SharePoint

You can use file shares and SharePoint sites at the same time, in parallel. But this does cause problems, which you want to avoid by unplugging file shares.

If you have both, it is:

  • Confusing for the users: what do we store where? In an organization where IT did not want to rush the unplugging of the file shares, some users complained that the old file shares ought to be switched off right away. If we are on SharePoint and others still on a file share, how can we find each other? And how can we get used to SharePoint if most of the information is still on a file share? Of course other users panicked at the mere idea of losing their file shares, which is why the IT department took it slow…
  • Costly for IT: storage on file shares is expensive, and you don’t want to spend time and money maintaining two systems.

But look before you leap

Organizations are often eager to unplug the file shares quickly, in order to achieve the desired IT cost savings. However, this can also cause problems.

  • Some files don’t work in SharePoint For example, supersized files or “dangerous” file types (like .exe) cannot be uploaded into SharePoint. Filename with symbols like & have to be changed before they can be uploaded. Connections of connected HTML-files, such as handbooks, can no longer be browsed when they are moved into SharePoint.
  • Is SharePoint really working for the users? Don’t unplug the old file share before the new SharePoint sites can really be used. Not only should the environment be available, but it should also be accessible without hiccups and perform properly. I have hear enough people complain that they did not use SharePoint sites because they are so much slower than the old file shares. Then they are only working theoretically, but not in real life.
  • Have the users been empowered to adopt the SharePoint sites? Do they know they exist? Do they see what the benefits are? Do they understand how they can use them to achieve those benefits? Do they feel confident enough to dare use them? Can they get support?
  • If not:
    • Old school users may revert to older tools If you unplug the file share and they do not see SharePoint sites as a good option, users may go back to sending files back and forth as classic e-mail attachments. Then you may get the IT cost savings, but you will end up with a mess of unmanaged information.
    • Savvy users will find their own tools in Shadow IT Some users love spiffy new apps and tools, and they want to get the job done. So they will just go out there, download this, subscribe to that and join anything else if IT does not provide great tools. I have heard enough users explain that SharePoint sites did not work for them, so they used Dropbox or Google docs or WeTransfer or whatever else instead. This may be just fine, but it may also be a risk if they adopt Shadow IT tools that do not meet the security requirements for example. And don’t think you can prevent this by blacklisting the known tools for file sharing in the cloud. There is always one that the IT official will have missed and that some creative user has found…
  • And transition carefully The best way to transition depends on who you are as an organization, what information you have in the file shares, and what governance rules your information has to obey. Maybe you can move the current information from a file share into a new structure in SharePoint as you go along and leave the rest for a year before you just delete it. Or you can migrate a nicely structured file share into SharePoint using a migration tool. But you should think about it, before you get some garbage-in-garbage-out migration or lose crucial information. And maybe you only have regular office files, without any complications, to which SharePoint is ideally suited. But you should make sure, before users have no other option but to put exotic files onto their C-drive (which may crash) or flash drive (which they may lose) or external storage tool (which may be pirate by who knows whom).

So for some types of files, you may need to keep a file share. For some organizations and some users, a file share may continue to play an important role. But for most organizations, most users and most of the information, it is a good idea to move to SharePoint and unplug the file shares. However, don’t unplug them before you have made sure that the users have adopted the new tool and embraced the new way of working.

October 31, 2016

Office 365 groups now have real SharePoint site

Filed under: Office365,SharePoint — Tags: — frederique @ 23:55

An Office 365 Group or a SharePoint Team Site? Now we mostly get an Office 365 AND a SharePoint Team Site: the integration between Groups and SharePoint gives us a full SharePoint Site when we create Group. At a later stage, we will also get a Group when we create a site from SharePoint.

When I talked about Office 365 Groups a year ago, I was not particularly pleased with them. They had potential, but also a lot of drawbacks. But these Groups are really getting somewhere now. Earlier this year I felt that these Groups were making serious progress. Then I enthused about external access. Now the integration with SharePoint sites is starting to make me a happy Groupie…

A SharePoint site for my Groups…

It took a while for the integration between Groups and SharePoint arrived at my Dutch first release tenants, but now all of my Office 365 Groups have a SharePoint site associated to it. Not just newly created Groups, also existing Groups.

When I am in the Conversations section of the Group, I even see an explicit link to the Site.

Link to the SharePoint site from the Conversations section of the Group

Link to the SharePoint site from the Conversations section of the Group

Clicking on that link opens the homepage of the SharePoint site associated to this Group. On the left hand side, we get the Quick Launch menu which we recognize from SharePoint.

The homepage is less recognizable, because it is the homepage of a Modern Team site, which looks quite different from an old-fashioned Team Site. This is actually the first Modern Team Site that I can play with, but that is a different story.

My Group has a full blow Modern Team Site, with a site home page.

My Group now has a full blow Modern Team Site, with a site home page.

I am very happy that I have a SharePoint site with my Group, because now I can:

  • Add lists for anything from the who-brings-what for the team barbecue to inventories of special solutions with their owners and statuses.
  • Use a page where I can bring information together. Not just the home page; I can create new pages if I want

… But I do not see a full SharePoint site

When I dug a little deeper in the site settng of my new “Group Site”, I saw that some options are missing:

  • Users and Permissions, with the site permissions
  • Look & feel: Title, description and logo, plus the Top Link Bar
  • Site actions: Save the site as template, and Delete this site
  • Most of the Web Designer Galleries
  • Site administration: Site closure and deletion, popularity trends
  • Site collection administration: Enterprise Content Management tools like audit log reports, content type policy templates and site policies,. Also popularity and search reports. And the sharepoint designer settings
Site settings in a site associated with  Group versus the settings of a native SharePoint site

The settings of a native SharePoint site versus the settings in a site associated with Group versus

So did these settings drop out of the site? No. According to Mark Kashman in the Q&A of his keynote at the Collab365 Global Conference, nothing has been taken out of the sites. However, some things have been hidden…

The options that are hidden in a site associated with a Group are the options that you are supposed to manage in the Group (in Outlook) instead of in the site, like its membership. You are also not supposed the delete the site but the Group as a whole. And he said that they had hidden the options that would confuse non-SharePoint experts, so that may be why we don’t get the policy stuff.

So

When I need full blown Enterprise Content Management functionality in a site, with Audit log reports and policies, I still create a native SharePoint site. But for “normal” collaboration, Office 365 are becoming the go-to option…

May 31, 2016

10 lessons learned in a Team Site migration

Filed under: Governance,SharePoint — Tags: — frederique @ 23:10

Recently I was in the lead in a migration project, in which we upgraded collaboration sites from SharePoint 2010 to 2013 and moved them to another location. Let me share with you some lessons I learned in that project. Some from friendly feedback, others from hitting snags head on. Some related to SharePoint, and others that don’t have anything to do with technology but are all about people: communication and process.

SharePoint

1.The content database attach upgrade method is quite handy

We had hundreds of sites to upgrade and migrate in a short time. There was no time and manpower to do it manually or to write a custom code solution to do the migration. We did have a migration tool at our disposal but that was not suited for bulk migrations, and the other tools we looked at we too expensive. So we decided to use the content database attach upgrade method.

We were quite pleased with the result: we did manage to migrate 551 site collections in one weekend, even though some were quite large. The content and settings moved along nicely, including timestamps and the names of the authors, even if they had left the company.

2.Ask a SharePoint developer to script clean-up in Powershell: automate repetitive tasks

Unfortunately, the old collaboration sites were chock-full of weird customizations. They had even customized the permission mechanism, for Pete’s sake… So we did not want to upgrade the sites completely as-is. We could have tried to reconfigure the sites manually, but that would be a lot of work.

So a SharePoint developer wrote Powershell scripts, to clean out the unwanted customizations and transform the sites. We could not get rid of everything, but after the clean-up, the migrated sites are a lot more future-proof…

  • SharePoint developer. We talked to other developers, but we found out that they could not write these scripts sufficiently quickly and accurately. The scripts had to tie into SharePoint functionality, so the developer needed a good grasp of the way SharePoint works.
  • Automate as much as possible before the migration weekend. We had a non-stop process over the weekend for the production migration, where people had to perform tasks in the middle of the night. That can be a recipe for disaster. So the developer automated as much as possible, so that he hardly had to type in any commands and took little risk of making mistakes.

3.Align the settings between the old and the new SharePoint

We found out the hard way that the settings in our new SharePoint 2013 environment differed from the settings in our old SharePoint 2010 environment. These differences pertained to exotic exceptions in our collection of collaboration sites, so we had not included them in our regular test cases. For example:

  • The threshold for the maximum number of items in a list has been increased in the old environment to 13.000, while in the new environment the lists complained after 5.000 items.
  • HTM and MHT files were opened in the browser in the old environment. In the migrated sites, users are prompted to save such files.

So next time, we will make sure to compare the settings and align them beforehand.

The team’s process

4.Test the functionality

We started testing at an early stage, from different perspectives.

  • Content: Is the content intact, including things like the number of items, the timestamps and author names, and versions?
  • Settings: Are the settings intact, including for example views, web part pages, permissions and site settings?
  • SharePoint functionality: did the we somehow break the regular SharePoint functionality or does it all still work properly?

We needed to know what the Site Owners and other users would get after the upgrade. Firstly, because the developer was able to fix some issues before the real migration, in his clean-up and upgrade scripting. And secondly, because this allowed us to warn the Site Owners which elements would not transfer well. Fortunately, this pertained only to functionality that very few sites used. For example, the Term Store is not part of the content databases. We left it behind, because nobody really used Managed Metadata.

5.Test the infrastructure

In addition to the functional test of the environment, we also tested how the migration would run on the infrastructure:

  • Disk space. Given the size of the content databases, how much space do we need on the servers? Do we have that space? We didn’t, so we requested additional space.
  • Time. How much time does the migration take on the servers we have? What if we add a server for parallel processing with our clean-up scripts?
  • Snags. What snags do we hit? For example, we found out that we had to install a feature that was no longer used but still referred to from within SharePoint. And we found out that some servers would pause in the middle of the night, if we didn’t take special precautions.

I am very glad we did several test runs, because in our first runs we got nowhere near the finish line  within the planned timeframe of one weekend. And after these tests and subsequent changes, we did manage to finish the migration of the production environment by Sunday afternoon.

6.Create a cookbook and timetable for the team

Especially during our migration weekend, the pressure was on and we worked round the clock to perform our tasks. Some tasks and some transitions between tasks could not be automated easily. So we made them foolproof in our process:

  • Cookbook: We could blindly follow the clear and explicit steps we had written down in our cookbook beforehand, based on our thorough tests.
  • Timetable: The SharePoint developer/architect who devised the technical migration method created an excel sheet with all tasks, with calculated fields indicating when they had to be started. The calculations for the planned times were based on the durations found in our tests, and the calculations for the actual/expected times were based on our progress during the migration weekend. This way, we all knew when we could expect it to be our turn.
Migration timetable

Migration timetable (thank you Macaw colleague Peter Heibrink!)

7.Keep the lines open

Part of our team was in The Netherlands and the others were in India. So we could not get together in a real-life “war room”. So we worked from our homes during that migration weekend, and we kept in touch via digital means:

  • Conversations in Skype for Business. This was our main channel for informal chats and voice calls, to check progress, ask questions, get answers, put forward suggestions and generally encourage each other.
  • An e-mail thread to keep all stakeholders informed when we moved to the next step. They could read the e-mail on their mobile devices – not everybody had to stay glued to their laptops for the entire weekend.
  • A list of emergency phone numbers, so that we knew how to call and wake up key people if anything got stuck.

The most important thing is actually not the digital communication channel, but the willingness of the team members to share their thoughts, to express any doubts or questions they had, and to answer questions. This way, we could really work as one team.

Communication with Site Owners and Users

8.“Beautiful” emails are ignored as spam. Make it functional and personal

We started with an email to all Site Owners. It looked like a newsletter, styled to fit the corporate look & feel. We regretted that decision, when at a later stage we heard that some Site Owners had completely missed the communication. They literally said: “nobody reads those emails in newsletter format.” Oops.

What worked best, were emails that:

  • Have a functional look. No fancy styling, just mail to a colleague.
  • Have a clearly visible key message, in the subject and in the first lines: what is the point, what do we need from you. For example: “Group Sites migration starts Friday May 20 18:00h: Check in the final documents and inform the users”
  • Make it clearly relevant for them personally as much as possible. For example, in the subject of an individual mail we put: “Can we delete the Group Site XYZ?”, when the owner of a big site hadn’t told us if he wanted us to migrate it. This take a lot of time, but did allow us to take some unwieldly sites out of the migration. And when we mailed the new URLs after the migration, we used a mail merge to send every owner a mail with their own name and specific link, highlighted in a clear but ugly yellow.

9.A self-service migration list helps, but you still need to process email replies

We set up a migration site (already in SharePoint 2013), with information about the migration, a discussion list for questions and remarks, and a self-service migration list:

  • Information about each collaboration site collection: In that migration list we put an item for every collaboration site collection, with key information: the main site owners as far as we knew them, the URL, some metadata carried over from the site request list.
  • Fields that we wanted input on: We asked the owners to check the Main Site Owner fields and change the names if needed. We also asked them to switch the status field, to indicate if the site should be migrated or could be deleted.
  • Dynamic views helped the owners and users find the sites relevant for them: filtered by Main Site Owner = [Me], grouped by department, grouped by status.

Within a few days after our initial mail to all site owners, about half of the items in the list had actually been updated by the site owners themselves. That saved us a lot of time and effort! But then again, about a quarter replied by email so that we had to administer their wishes. It was more important to us that we actually get an answer than that this answer was given via our preferred channel, so we thanked them anyway. And the rest had to be chased to elicit any answer at all. Fortunately, we had decided that if we got no response from the owners, we would simply migrate the site to avoid getting into time-consuming fights..

10.Asking the Site Owners if they want to migrate their sites is worth the effort

We contacted the site owners, because we wanted them to take a small part in the migration: make sure their site was ready for migration and inform their users. So we asked them to confirm they were the main site owners we should contact.

Because we were mailing them anyway, we also asked them to tell us if they wanted to migrate their sites. We fully expected everyone to blindly respond that of course their sites had to be migrated, especially because 6 months earlier we had sent out a regular request to delete inactive sites. But lo and behold, it turned out that the site owners said that a full 26% of all collaboration sites could be deleted! That saved us a lot of time during the migration weekend.

January 31, 2016

How do I create a document in SharePoint?

Filed under: SharePoint — Tags: — frederique @ 23:27

We often see users creating documents in MS Office and then uploading them into SharePoint. But you can also create your document directly in SharePoint. A client recently wanted to know the details, because they feared that their newbie users would otherwise never put their documents in SharePoint.

So how do you create documents in SharePoint, particulary in SharePoint Online?

Use the button ‘New’

To create a new document in SharePoint, you navigate to the site where you want to create your document. And in the Document Library you click the obvious button: New. Then you select the type of document you want to create, Word for example.

'New' button in a Document Library, to create a new document.

‘New’ button in a Document Library, to create a new document.

Create a basic document in Office Online

By default, this opens Word Online (or another Office Online, if you have selected another document type). Here, you can just start typing your document…

Write your document in Word Online

Write your document in Word Online

The system has not asked what you want to call your document. By default, it is called Document, which is not very helpful. So remember to change the filename: just click on the filename at the top of the screen, in the screenshot click Document, and type your own name.

And when you are finished, you do not have to click Save; the document is saved automatically. The actually is no Save button. When you click on the name of the site (in my example Operations), you go back to the Document Library where you started, and the document is saved automatically, by the filename you have entered at the top.

Please note: if you have not entered your own filename, the document is still called Document or Document1 or something similarly unhelpful. Edit the document again in Word Online, to change the filename.

Edit your document in Word Online.

Edit your document in Word Online.

Create an advanced document in Office

In some situations, we want more than to just type up a document. We may want to use a template, and add metadata to make it easier to find the document. In that case, the Site Owner should set up the Document Library differently.

Use a template for a Content Type

If there are templates for, for example, reports, then it is helpful if the Site Owner or the overall Administrator creates a Content Type for them and associates the template with it. For an overview of the steps, see Microsoft’s Create or customize a site content type.

The relevant part for the template is in the Content Type’s Advanced Settings:

In the Advanced settings of the Content Type, the Site Owner can upload a template.

In the Advanced settings of the Content Type, the Site Owner can upload a template.

When the Site Owner associates this Content Type with the Document Library, the user can select it under the New button:

Add a report from a custom content type.

Add an Opeations report, based on the custom content type.

Now, the problem is that such templates do not always work well in Office Online: images may float to the wrong place, dynamic fields are not filled properly. You may want to test this with your own template. But be prepared for the fact that the Site Owner may have to change the settings, to use Office on the desktop instead of Office Online. We will get to that in a minute.

Use metadata to structure the document collection and find documents

If you have a lot of documents, it is helpful to group them by category, for example. Or filter them by status. Sort them by End date. In order to do that, the contributor who creates the document needs to fill in these metadata.

In Office Online, this is a bit tricky.

When you upload a document, you are prompted to fill in its metadata. However, if you create your document directly in Word Online, you are not prompted to fill in anything but the text of the document.

So if you just write your document and let it be saved automatically the metadata won’t be filled in. And if some of the metadata are required (like a Report category) then the document will remain checked out. That means that it is a draft version of the document, which only the uploader can see and nobody else.

The required field Reportcategory has not been filled in, so the document is left checked out and invisible to other users.

The required field ReportCategory has not been filled in, so the document is left checked out and invisible to other users.

The contributor then has to be aware of the situation, edit the properties, fill in the metadata and check in the document. The problem is that many contributors will forget that, and this will play havoc with the usefulness of the SharePoint sites.

This works a lot better if SharePoint opens the document in MS Word on your desktop, instead of opening Word Online. You are still working directly from SharePoint, but just in a different version from Office.

Opening documents on the desktop instead of in the browser

The Site Owner can determine where documents are opened, when you click on the title to read them or when you want to edit them. This is in the Advanced settings of the Document Library: in the section ‘Opening Documents in the Browser’ select Open in the client application instead of the default value ‘Use the server default (Open in the browser)’.

In the Advanced settings of the Document Library, the Sit Owner can select to open files in the client instead of in the browser.

In the Advanced settings of the Document Library, the Sit Owner can select to open files in the client instead of in the browser.

The document then opens in Word, where you have all functionality at your disposal, including fully functional templates.

And part of that full functionality is the Document Information Panel: a panel at the top of the .document with fields for the metadata. Please note: this Document Information Panel (DIP) appears in Word 2013, but not in Word 2016.

The document opened in the client, MS Word, with at the top the Document Information Panel.

The document opened in the client, MS Word, with at the top the Document Information Panel.

The Site Owner who manages the Content Type can configure it to “Always show Document Information Panel on document open and initial save for this content type”.

Content Type settings for the Document Information Panel

Content Type settings for the Document Information Panel

The Document Information Panel settings

The Document Information Panel settings

 

So users can create documents directly in SharePoint, so that you do not have to worry about documents getting stuck on personal drives or local computers. How the Site Owner should configure the site to make things easy for the users, depends on the situation.

  • For basic documents, without templating or metadata, working in Office Online meets the needs. In particular for users who do not have Office on their computers. Do not forget to tell users that they can change the filename at the top of the screen.
  • For advanced documents, with templates and/or metadata, working in the Office client (MS Word on the desktop) is easier. For that purpose, the Site Owner should configure content types and change the advanced settings of the Document Library, to open files in the client.

September 30, 2015

Older Posts »

Powered by WordPress