Coming Soon! GEBestBetAdder GUI for SharePoint 2013, 2016 and SharePoint Online

Coming Soon! GEBestBetAdder GUI for SharePoint 2013, 2016 and SharePoint Online

Things have been very busy at the Geoff front. Work on the GUI version of GEBestBetAdder is being finalised. This tool will help you migrate and manage Best Bets from SharePoint 2010 enabling you to migrate to Promoted Results in SharePoint 2013 and beyond, including just some of the following features:

  • Create Query Rules and Promoted Results into SharePoint 2013 and beyond from SharePoint 2010 Best Bets and Keywords
  • Add, Edit and Delete custom Query Rules and Promoted Results without having to access SharePoint
  • Export Query Rules, Promoted Results to Excel and XML formats
  • Manage existing Query Rules on a site by site basis

The tool has been long in the making and has been great fun to build – its absolutely crammed with features. The tool will be made available on a trial basis very soon, am aiming for release by end of August 2019. It will even include the ability to migrate Query Rules to/from on-premise to Office 365. If you are interested please contact me and I’ll add you on the trial list.

Service Delivery and Automation

Service Delivery and Automation

Oh yes, I love automation. Having a mountain of robots, and building them (especially my DR Who full sized dalek), fascinates me in the wonder how invented things can move without human intervention (except I suppose the dalek because I will be driving it – haha).
himandherrobot
There are various products which all elude to automation in my arena of Microsoft Office systems and services. And now that they are being brought all together under the Office365 hood, now is the time to understand the nature of Service Delivery and Automation.
This quick article is my take on what it is from my standpoint giving some arguments as to what it means from a basic viewpoint. Note that this view is one I have had for many years, because the model, and my notion, stems all the way back to my Systems Analysis days.
Ahem, a little check first… Automation and associated service delivery has been around in systems since the age of software. It is not new. Unfortunately, by many, it is an art which is glossed over, and as such, when someone says ‘lets automate process using powershell’ that’s only a small link in chain mail armour. But now, we have entered the realm of convergence, the advent of ‘connected’ systems. This means automation takes an evolved step, into the land of systems with software beyond human reach, beyond scripting, beyond coding, beyond one platform (e.g. SharePoint), beyond Office365, into and beyond cloud services, to the nether regions of connected systems and connected data. The fact that more data is available to be accessed which can then be scrutinized, re-modeled and then used to automate other processes makes this an exciting time in the land of software design. The fact that time-to-live for the company process becomes shorter, the re-use and revamp of automation becomes an enterprise imperative, and the need for a complete ‘coded’ approach is not the answer. Also, the following video gives even more reasons why automation and service delivery are becoming more important.

Why Service Delivery and Automation is important

As a younger lad, having been introduced to Systems Analysis and Design (which includes programming in a multitude of computer languages using a multitude of platforms and technologies), as I see that as time marches on with new technologies, so does the increased need to maintain and therefore automate, endpoints of legacy with endpoints to current with endpoints of the ‘external’. Critically, and in every solution devised, there is service delivery. The absolute imperative to ensure that whatever solution being devised is maintainable, available, repeatable by design and resilient. This resiliency is not just to do with things like Disaster Recovery or Business Continuity, it goes right to the heart of making sure that the solution is fit for purpose. Service Delivery flows through every part of enterprise architecture, from the idea, to analysis, to design, to production, to support and thrives within that solutions and connected solutions lifecycles. It includes the physical and digital technology that makes up the solution – yes, the servers, and the software, and the storage etc. That means, that even more crucially, it does not matter whether you are a business analyst, a programmer, an administrator, an engineer, a product manager or programme manager. You will be thinking service delivery in whatever you do, whether you like it or not. As you may know, my site is a haven to all things service delivery and includes another passion of mine, which is automation. Why? Because automation is the connector that allows the solution to be flexible, to scale, to morph, to carry out processes without human intervention (which then means better accuracy) – it supports service delivery. Of course, I don’t aim to create a wonderful robot of automation to win a prize, but am absolutely keen to learn and use my integration expertise with it! robotaward Anyway, lets go back to why you should understand the importance of service delivery automation. For example, lets quickly mention Office 365 as an example. Any administrative process that you are carrying out when interacting with the admin centre of Office365 carries out a robotic process. A robotic process is one where you interact with the product, and yet, the back end product is not wholly under your control. Rather, you are automating the software to carry out functions, as opposed to you directly influencing the software. You do not have access to any server based tools – you are automating those tools to carry out a process, in fact, you are being non-invasive – that’s robotic automation. Robotic automation also includes things like system upgrade, data entry and transactional processing. And the high  chances are that you will not have direct access to those systems in a multi-departmental organisation. Robotic automation is definitely coming on leaps and bounds in a multi-server environment where you need information from a collection of systems. I spoke to a company which has a desire to manage specific services wanting to not only control web services on a particular group of pre-production servers, but also wanted to store results securely online because they had support groups which did not have access to those servers.

Automation comes with a price

But automation carries with it a price. The increase in automation has a detrimental affect on wisdom, that is, it will curtail the ability to continually review an already automated created process. Reasoning is that once something has been automated, it is then difficult and/or cumbersome, and therefore not desirable (particularly for large automated processes), to alter that process, without then impacting on other processes connected to it. Take for example the process to automatically upload data into SharePoint which then automatically stamps metadata on that data. Lets assume for a moment that it starts off as simple as this:

  1. Get a file from a network share
  2. Upload that file into a SharePoint document library
  3. Set metadata, the Title becomes the filename

Sounds simple? Yes, until you add a simple automation with that file, like:

  1. Once the file has been uploaded, alert the members
  2. Gather details from the file to pass onto a data management system

For alerting, sounds simple because you would simply set an e-mail alert, yes? But it is not so simple if that alert needs to be customised beyond what SharePoint does, or if the alert needs to trigger some other process, like having its contents interrogated to be used in another system. And as for the data being passed onto a data management system, that means additional management of ensuring the right data gets across. Then there’s the service delivery angle, ensuring that the automative process continues to be maintainable, available, resilient and supportable. So that means, either code it, or use say a workflow to customise a notification that fires as soon as the file is added and carry out other functions. The point is this. Once something becomes a target for automation, the human desire to do more with it comes arises, but that impacts on wisdom because the need to change things does not happen at the same speed as when the process came into action. This speed decreases with every new connection to systems and other processes, because of amount of work required to identify and service deliver all steps in the process end-to-end. This affects wisdom, as the sheer added number of steps in a process make it more cumbersome to confirm things like performance, audit, human response tracking, etc. Of course, one may argue that certain workflow tools tracks performance in each step. But that rarely comes from a central point – that generally comes from the application system running that step. If are able to centralise all processes under one system banner, then maybe, well done! But, I am not talking about just one tool. I am talking about automation that does not just include that tool working in one system, but all the other systems that tool may be a part of in an automative process (that is, all endpoints).

Automation is not just writing an app to display a form or a workflow

In essence, automation is one of the keys in which systems work in harmony to fuel a seemlessly connected process, machine driven and harvesting intelligence. Service delivery automation encompasses all parts of a process that requires automation in order to meet one or more of the imperatives at the bottom of this section. It is more than simply the need for someone to fill in a form (that is simply an aspect of a process).

For example, if HR wants an individual to fill in a form online once they are on-boarded, that form must be sent to specific individuals, then to other departments to assign resources, then needs to be stored, and needs to be applicable to audit (or used again when that new person changes departments or even leaves the company). So writing an app to get someone to fill in a form is not automation of a process, it is a step in that process. Another example. You want to be able to collect information on the status of all servers in your estate – specifically, the status of specific services and want to display that centrally. You don’t have access to SCOM (System Center Operations Manager), and you don’t want to code it. Again, writing an app to display the status of all the services is not automation of that process, it is a step in that process, because automation of display of that information does not end with it simple being displayed. You want to be able to act on the data, or take some automated action to resolve issues if the status is not as expected.

docaut

Automation using any technology is decided upon because one needs to address all of the following, but only works if by connecting technologies using automation techniques minimises disruption:

  • Quality
  • Speed
  • Accuracy
  • Productivity
  • Efficiency
  • Scaleability
  • Flexibility

Don’t automate everything!

Just because you have a bicycle does not mean you fix it so it rides itself. By doing that you miss the simple enjoyment of doing anything physical, like exercising your legs. The same thing comes with automation. Just because you want to cut costs to achieve additional benefits by reducing or eliminating human involvement doesn’t mean you should immediately automate the process. A factory which distributes milk has automated the entire factory floor so that robots move the milk containers around the factory. But they still need humans to keep an eye on the robots. Certain processes you will want to be operated by humans, because at the very least you will still maintain some modicum of control, and to mitigate risk. Otherwise, you might as well consign yourself as a cyborg or a member of the Borg from Star Trek. You only automate things that you think will reduce time around time, or will reduce the requirement to chase actions. But improving things to simply reduce headcount is not going to solve anything, unless you can absolutely guarantee that nothing will happen to upset the automated process. Some companies where automation has been a success is were they actively introduce business continuity. I’ve even seen companies use a back to paper continuity plan if the automated process through computers fail. This is where, for example, they utilise legacy equipment and where they need to guarantee a process if that legacy equipment fails.

Conclusion – and a new beginning?

If you are not thinking automation for your technology set, you should be. I think that it is time to take stock of your automation alternatives. Automation of an enterprise solution using multiple technologies requires an adoption of an suite that allows you flexibility. Remember that using a tool within one platform is not enough. Maintainability, Availability, Resiliency and Supportability is key. Automation in the SharePoint space is already taking place, is driven by transactional processes across systems, to ring-fenced workflow against specific processes, to Web Analytics across Office365 and on-premise SharePoint. As this increases, so will be the need to review automation tools. On my voyage of discovery, a few of the companies I have surveyed taking automation seriously have mentioned to be a product called Automate 10,  owned by HelpSystems LLC. This product provides a none scripting platform to integrate and automate a myriad of services from Amazon through to FTP through to WMI automation and across multiple servers and services in the enterprise. Am running some demos of this myself and the product seems to be very useful. Check out some automation case-studies from some products which I recommend if you are considering enterprise wide automation (not sticking to one technology or one sticking to one scripting language). Click the below screenshot to see the number of services (note – Azure is also listed!). automatescreenshot There are other links to articles you should also check out, to see how some other organisations are dealing with automation.

SharePoint and the Workflow Conundrum

SharePoint and the Workflow Conundrum

When utilising a collaboration tool the key productivity rationale is to automate processes through the content stored within that collaboration tool. SharePoint has a number of platform flavours (on-premise, hybrid, online) and has integration points which is only limited by creativity it seems (not simply confined to Microsoft products). Therefore, it is crucial that when thinking of what workflow tool should be used to automated business process that you understand also the options, strengths, weaknesses of the various workflow options that can be utilised with SharePoint.

Having had a lot of fun trying to fathom, making mistakes along the way of course, I got together all my notes, including querying lots of knowledgeable people (thanks to you all) – and put together an article; published on Tech Net blogs and also on DOCS!

The article is quite large therefore I had it split into four parts (great idea from Charlotte C at Microsoft – thanks)

Sections in Part 1 are:
1: Introduction to the business process automated
2: What does a workflow system need to accomplish
3: Mind set of developing workflow
4: Types of workflow
5: What does the full article cover in terms of product, scope

Link: http://blogs.technet.com/b/uktechnet/archive/2014/12/10/part-1-sharepoint-workflow-service-delivery-options.aspx

Sections in Part 2 are:
1: Options for workflow with on-premise SharePoint
2: Options for developing custom workflows using SharePoint Designer / Microsoft Visual Studio

Link: http://blogs.technet.com/b/uktechnet/archive/2014/12/18/sharepoint-workflow-service-delivery-options-part-2.aspx

Sections in Part 3 are:
1: Options for workflow in SharePoint Online through Office365
2: Options for workflow in hybrid situations
3: The ‘workflow manager’
4: Publishing workflows to Azure
5: Workflow options available through third parties
6: Strengths and weaknesses of covering all options

Link: http://blogs.technet.com/b/uktechnet/archive/2015/01/19/sharepoint-workflow-service-delivery-options-part-3.aspx

Part four completes the article by summarising the key take-away – what tasks should be carried out concerning an approach to choosing the workflow solution that suits you and the customer

Link: http://blogs.technet.com/b/uktechnet/archive/2015/01/26/sharepoint-workflow_3a00_-service-delivery-options-_2d00_-part-4.aspx

Happy reading!

Creating a Repeatable SharePoint Solution Delivery Process

Creating a Repeatable SharePoint Solution Delivery Process

This is the second part of the article concerning the delivery of SharePoint solutions. I will start by recapping on why I have produced these set of free articles, which will combine into an e-Book soon, check out this article. In essence, a successful solution delivery process encapsulates a design, creation, provision and support framework – that’s what makes up a SharePoint solution.

As stated in the first article, I am not designing a new process, rather, giving ideas surrounding theory, and actions for the reader to use.

The first article in the series, first looked into the understanding of creating a Usable SharePoint solution. A usable SharePoint solution takes into consideration the service standards applicable like design, development, commonality, consistency, tools and cross platform standards that can be applied when working with SharePoint. In learning the standards relating to usability, repeatability, supportability and extensibility you will be able to continually provision solutions easily, slicker and also help the client learn how to manage the solution once handed over.

A danger in writing these kind of articles is that the reader may be fooled into assuming that this is a business article, and somehow, not related to anything technical in SharePoint. In fact, service delivery is combination of the two – known as Systems Analysis which has been around as long as software has!

This is the second article in the series, concentrating on the key aspect of providing a sustainable solution – repeatability. In essence, this is the use of common processes, components, and products to build SharePoint solutions; continually – meaning using a repeatable method. Before thinking ‘this isn’t for me’ – wrong. As a SharePoint worker, you will be using a ‘repeatable’ process when even the simplest of SharePoint site solutions. For example, a document template re-use is defined as using a repeatable process. A web service that provides solutions such as say copying files from one place to another can be set to carry out the same process on another source and destination with minor customisation. Even a SharePoint site carrying a common structure can be easily created using a template, such as a Team Site Template. Apps are ‘repeatable’. Other examples could include workflows which are re-purposed, like Approval workflows.

The challenge is that most people, faced with constructing a SharePoint solution using components do not understand the principle of re-use which is a key aspect of a repeatable SharePoint solution delivery process. They may understand that something such as a template can be used again and again of course; however, they do not understand why a process ensuring why and when that a re-use management process can be applied; from the lowest component, to sites, site collections, web applications or farms. Even the provision of an Office365 tenant to a client is defined as a repeatable process. If there is no understanding, even a laissez faire approach, no standard or structure applied. And, as time marches on, as components morph, change and multiply, the potential for chaos ensues, where people simply have no idea what component should be used for what solution – instead, a patchwork of ‘guessing’ takes place!

Time I think to put a spin on helping you understand the principles of a ‘repeatable’ SharePoint solution. Again, this is a really challenging article to write, but an enjoyable one as well (like all my articles!).

First, time to get back to basics. Am going to start this section with a strange analogy – IKEA tables.

I went to IKEA Edinburgh last week looking for tables. My partner wanted some new tables to brighten up the conservatory, the kitchen and the cinema room. Now, browsing around IKEA for tables (well in fact anything in IKEA as I am not a great shopper) can be a bit of an experience, and sometimes, an annoyance. Trying the find the right colour, size took a huge wedge of the day to find what would look right.

So, in the end after hunting for tables in IKEA, we decided on three tables, put them into the horsebox and drove back home with them. Once home, I spent the following day putting the tables together. The first attempt at building a table was a nightmare. Yes, the instructions are easy to follow, but unfortunately I am not that great in following IKEA instructions; I dove in blindly with the screwdriver – then once I started getting things wrong, I went to the manual. It took me over 3 hours to build the table. Finally, I managed to put the first table together. Then, onto the second table. This was easier to put together, simply because I remembered all the wrong things I did about the first, and because I followed the manual :). The third was such a blur of activity – I simply didn’t need the manual, and I placed all the components in the order of building – the time taken to build was a fraction of the time to build the first.

Of course, stating that building tables is not a great and wonderful idea of delivering SharePoint solutions using repeatable exercises. But it is a great analogy because of two key reasons:

  1. All components fit together because the form an object
  2. A manual is there to guide you through the process

That means this two simple reasons can easily be applied to SharePoint to ensure a repeatable process. Surely it is easier to put a SharePoint site solution together if there are common components that can be reused at will? Surely, if there is a documented process that aids the creation of the SharePoint solution which utilises those common components, then that defines a repeatable method of creating those solutions. However, the concepts I have mentioned are unfortunately not carried out, or is a challenge to understand how to put them in place – and this is because the capabilities that describe how a SharePoint solution can be made ‘efficient’, through its delivery process is not at hand. I am going to attempt to address that, by describing the key capabilities that make the SharePoint solution efficient in terms of its development, deployment and maintenance.

The capabilities that you should consider, which in my view help you create a SharePoint solution (requiring the roles of Systems Analysis, Development, Architecture and Administration) and by definition can help build a ‘repeatable’ framework are:

  • Create Service Blocks. Service blocks are a common set of high level components that can be reused. Examples of these are pre-configured Apps (site, repository, third party products and integrated services, workflow templates) which can be combined build SharePoint solutions. A great example of this are workflow templates that can be constructed by the fabric ‘or snippets’ from other workflow templates (Nintex provides a great way of doing this).
  • Set a Common Schema. Creating a common format that can be applied to multiple solutions. Examples include branded custom pages, format of the quick launch bar, top line bar, enterprise taxonomy, navigation, etc. House the combined solution designs in a central location armed with keywords and categories to identify them.
  • Discover and build the skills necessary. Creating a common set of training and guidance material for the solution that allows the user-base to learn the product, explore and use the relevant possibilities that are available.
  • Ensure products can be Self-Provisioned. Users are empowered if the solutions they have constructed can be re-used to solve likewise problems for themselves and others. This aids the productivity of the individual, their peers and enhances the ability of support.
  • Build Enterprise Policies. The creation, re-use and management of policies which will aid in the adoption, design, structure, implementation and deployment of the solution.
  • Factor in Deployment Management. Drives the configuration management process whereby a SharePoint solution can get from idea to Test to UAT (User Acceptance Test) to Production. Aids the version control management of the solution in terms of how the solution can be updated and upgraded. Aids the document and data control process so that the solution can be adequately documented.

Service Delivery

Service delivery of the relevant solution needs to be efficient. This means being understood and managed by the stakeholders, since they are responsible for managing / devolving the management of the solution going forward.

For Service Delivery to be efficient, the solution delivery mechanism needs to be carried out in a sequenced and logical approach that the customer will understand and be part of. For example, if SharePoint is going to be employed in an organisation, the client needs to understand the part that SharePoint is going to play. This means understanding the information framework, and applying that, including controls for managing and locating that information. The fact that SharePoint is going to be used is irrelevant at that stage, since through the evaluation of the information flow in the organisation, the tools being used, the culture of the organization, amongst other key issues like control, security will influence the platform being employed.

So, a service delivery mechanism which encapsulates vision, decision, design, build, support, sustain, control needs to be defined first. A key outcome of creating a service delivery mechanism provides the stakeholder with the knowledge and comfort that an understood process (which they will manage) is clear and can be adhered to.

This means providing a number of service blocks that can be provided whenever releasing a SharePoint service. Examples of this are:

  1. Maintaining and managing a list of owners that also concerns who the owners are, the key stakeholders and users.
  2.  Maintaining and managing a list of the key resources used both SharePoint oriented and people who will be using the solution

Efficient Service Deployment

There is confusion on the terminology surrounding the term ‘Service Deployment’. It seems that it is a technological term, and therefore, something related to getting some software from somewhere and installing it. I have witnessed situations where someone says ‘We are going to deploy the software service by following the installation process given in the manual’. In other words, download the product from somewhere and follow the automated installation process by clicking ‘Setup.exe’….

No.

Service Deployment is the process under which the SharePoint solution is deployed from a full implementation perspective and involves all resources necessary for that to take place. That means including people. That is the first simple rule. Keep the users involved.

Example. An app has been sanctioned to be deployed to a SharePoint online team site. The procedure that was followed to get the product sanctioned is a tried and tested method of user requirements, testing, user acceptance.

Efficient Service Deployment is part of a Software Delivery Process. A process by which the deployment of the solution is simply part of its lifecycle. That lifecycle includes the design, build, maintenance, support and any other aspect that defines the solution.

Henceforth, knowing what makes up the SharePoint solution is vital since that naturally produces the information required to ensure that the solution can be deployed. There are a number of documents which should be created:

  1. Hardware Components
  2. Software
  3. Installation Guide
  4. Related Productions
  5. UAT Provisioning
  6. Release Notes

Capability

Because the people must be capable in using the delivered SharePoint solution. Therefore, the solution must be capable in enabling and enhancing business productivity, knowledge, and solving information and management collaboration challenges.

So, in order to repeat the process of creating successful SharePoint solutions, the capability (structure, roles) of the support service team responsible for designing, crafting and, deploying and most likely supporting the solution must be repeatable from solution to solution.

This means that:

  • SharePoint support services must be capable of supporting the delivered solution in line with customer expectations
  • SharePoint delivery teams must be capable on delivering on the promises that were made about time and quality
  • Any relevant SharePoint support services must be capable of standing over any key performance indicators or service level agreements.

Scalability

Scenario: You are going to deliver a SharePoint platform to a client. You gather their information requirements and process. You provision a ‘Proof of Concept’ SharePoint platform open to key stakeholders to showcase, demo, and gather further requirements. The client wants SharePoint. From there, you provision a UAT (User Acceptance Test) environment which maps to their requirements in terms of infrastructure, availability, scalability, extensibility, support. You then open that up to key stakeholders. Workshops ensue. The client still wants SharePoint, the UAT environment provided appears to meet functional and system requirements. You then provision a Production environment which matches the infrastructure provided at UAT level, and then deploy SharePoint services to the client as prescribed in UAT.

The above is a simplistic approach concerning the delivery of SharePoint to a client, following a design, build, deploy process. A repeatable SharePoint Service Delivery mechanism focusing on implementation.

However, the point being made about the scenario given about is a word which encompasses the delivery – future-proofing. ‘Future-proofing’, means that the solution being provided will not only meet the client requirements at the point of inception, but can also in the future because it can be scaled, and therefore will continue to meet changing requirements.

Scaling a SharePoint platform and any relevant solutions is not a single event exercise. Any alteration, addition or deletion to the solutions provided within the SharePoint platform requires a review to determine the impact on the scalability of SharePoint. For example, take the addition of a third party app to SharePoint, which becomes important, an app which the users cannot do without. The impact to the scalability of SharePoint comes into question if, for example, that app cannot itself scale to the next ‘hotfix’ of SharePoint, let alone the next version of SharePoint!

Actions

A lifecycle of delivering SharePoint solution needs to be based on being repeatable. Reasons for doing this have been stressed in this section, but to summarise:

  • Stakeholder map per solution. Carrying analysis on the gathered maps will show connections between the common components being used across multiple solutions and also the key individuals helping to create a focal / champion group.
  • Efficient Service Deployment. Due to re-use, there will be reduced requirements to bring in key resources build likewise solutions and components leading to reduced cost and management issues.
  • Efficient Maintenance. Updates to repeated solutions can be applied generically, change management is easier to define, business policies and rules related to the solutions are easier to enforce and get buy-in.
  • Capability. Users and Support gain knowledge and maintain that knowledge more readily than disparate solutions non repeated solutions.
  • Scalability. Easier to plan, coordinate and carry out configuration management processes on repeated solutions.

In the Scalability section above, I gave a simple scenario based on deployment of SharePoint and boiled this into a repeatable solution exercise. That’s not the only scenario that uses Repeatable as a method to service deliver SharePoint solutions. SharePoint provides virtually all the components and tools that allows components to be configured, connected and scaled. SharePoint provides the ability for modules of functionality, developed internally or externally to the organization and contained in Apps. Apps that can be re-deployed, and further enhanced based on changing needs of the client, and can be deployed centrally from a bank of other Apps. For example, a simple document library App may alter need the ability to be connected to a third party tool, or may require further enhancement concerning views and sort, or may be required to lookup information from another repository. When completed, the entire configuration of the document library can be transformed into an ‘App’ which can then be redeployed elsewhere without having to re-develop from scratch. Other Apps include Site Apps, and Third Party Apps.

Third Party Apps throw a different kind of repeatable solution scenario because of the added dimension in providing automation, which then leads to the ‘Supportable’ element of the SharePoint Service Framework. This is simply due to the fact that Third Party Apps cannot be successful unless there is a support group. The sheer number of Apps available from the Office Store for SharePoint compounds scenarios concerning re-use, consumption, implementation and administration.

As per all things when implementing a solution in SharePoint, the answer to solving business and information challenges requires you to continually and critically review the requirements to find nuggets of functionality that has already been created. Analyse thoroughly the various elements of the SharePoint solution, so you can identify common areas that can be defined generically and as repeatable components. Harvest them into deliverable chunks and rework to see if they can be repeated. Remember the DEV to UAT to Production model – this applies to any kind of solution (design, develop, test, make it live).

If this sounds a little convoluted, remember the client perspective. Generally, they will not care what the resolution is made up from, is as long as it works – however, they will care, if the solution is usable, whether the solution once implementation can be repeated to meet a likewise requirement elsewhere without having to pay extra, whether the solution can be supported and whether the solution can be extended as the SharePoint platform scales.

Before going onto the relevant actions concerning what you need to implement, how the customers can consume, and how you can administer a SharePoint solution that can be repeated, check out these articles which all have a bearing on this section.

In conclusion to this article, which I will continually come back to update, you should also consider the three actions that you should consider in building a ‘repeatable’ SharePoint solution framework – Implementation, Consumption and Administration.

· Implementation

  • List the common attributes of ALL solutions and group them into the four key aspects of SharePoint service provisioning – Support, Automation, Management, Reporting
  • When designing solutions, record aspects of those solutions (if not in their entirety) that could be included in other solutions into a knowledge base.
  • Record the aspects that allow third party products to export configurations that could be re-used. For example, you could develop a simple SharePoint site that houses developed and them exported Nintex workflow templates, thus making them accessible for re-use to others. In other cases, you could even export workflow templates and have them available for download in other sites.

· Consumption

  • Build a process whereby users can provision solutions which are available in a library.
  • Communicate available solutions and review all solutions in that library so that you can be sure they are being used effectively
  • Record usage of the solutions in terms of where, how and popularity of the solution

· Administration

  • Create enterprise policies that ensure users follow rules in terms of re-using ready-made solutions and link them to support
  • In relationship to consumption, associate business rules and policies concerning the solutions that are in your library of solution

This article is part of Delivering SharePoint Solutions – Areas of Importance.

 

GEGetDocConfig – SharePoint tool – List Document Libraries, Structure and Security

GEMySiteLockDown – Automate MySite Lock Status – and Removal

Was asked today – is there anyway to remove Mysites en-mass in SharePoint 2010?

Yes, because I’ve written a free tool available for download that works using the following parameters:

-a  Create file for ALL sites within the chosen collection
-d  Create file for sites within the chosen collection that have been modified in the last day.
-w Create file for sites within the chosen collection that have been modified in the last week.
-n  Lock State is None
-x  Lock State is NoAdditions
-y  Lock State is ReadOnly
-z  Lock State is NoAccess
-u  URL of the Site Collection whose subsites you want to lockdown

(more…)

GEGetDocConfig – SharePoint tool – List Document Libraries, Structure and Security

GEPDOCPERMS – Free Display Document Libraries and Permissions Utility for SharePoint 2013

Hi Folks,

For some time now I put down the SharePoint automates pen, but, seeing as 2013 is definitely out I thought, hey lets upgrade and develop all the tools and release new ones in my ‘suite’. GEPDOCPERMS is a new utility, one of my favourites, it’s a free download and it is available for SharePoint 2013. GEPDOCPERMS is a utility that will list document libraries from all or a specific SharePoint site, with the ability to show the permissions set against documents, the ability to list the email enabled document libraries, the ability to list permissions against a specific individual. The output of this utility is TEXT, however, further releases will include the ability to write to XML and HTML.

(more…)
SharePoint 2013 Helpdesk Site Available

SharePoint 2013 Helpdesk Site Available

I have created a basic SharePoint 2013 helpdesk template which you can try out, modify and apply as a helper to their SharePoint support desks. The reason for supplying this is to (a) give an understanding of the ability of SharePoint to provide basic helpdesk functionality using built in features and (b) to introduce you to the concept of centralising a helpdesk in a ‘one stop shop site’ concept. Please note, I am not providing this as a suggestion that you drop any helpdesk product you are using – this is not supposed to in anyway detract you from using that!!

(more…)

GEGetDocConfig – SharePoint tool – List Document Libraries, Structure and Security

GEPBACKUP2010 and 2013 – automated script generation utility to backup SharePoint 2010 and 2013 Sites

Introduction

From a conversation I had with a SharePoint Administrator:

“Eeee. The client wants site by site backup – that’s going to take me a while to sort out. I need to backup 500 sites via command line but want to know how big the sites are. I also need to know how long each backup took. I know SharePoint has Powershell but I simply don’t have the time to write a script – also, I only want to backup sites which have changed either today, this week, or just want to backup them all up”.

(more…)
GEGetDocConfig – SharePoint tool – List Document Libraries, Structure and Security

GEGETListInfo – SharePoint tool to mass obtain List IDs (GUID) in SharePoint 2013

Introduction.

Trying to extract a GUID from a site component directly is a hassle. And the developers always asked for a GUID from a list etc. Options was to give them Design Rights to a List so they could use the ahem ‘Famous’ hack of extracting it from the List Settings, or writing a script! I thought, aha, a script sounds better, but lets give it some options!

GEGETLISTID gets the list title, description, number of items in the list, the list items (and optionally the ability to turn that output off) and of course, the List ID! It works against all components of the site, e.g. Shared Documents, Calendars, Tasks, Web Parts List, etc. GEGETLISTID works against a site, do you must enter the name of the site when running the command.

The output can be pushed to a text file of your choice or by default goes to GEGETLIST.TXT

(more…)

GEGetDocConfig – SharePoint tool – List Document Libraries, Structure and Security

GEMBackup – SharePoint tool to Automate SharePoint Site Backups

The command line backup / restore routine in SharePoint environment whilst good does not offer any scheduling capability. There are of course products providing granular backup (e.g. DOCAVE) but this is geared to corporate site collections. This document describes the GEMBACKUP application, that can facilitiate the backup of the SharePoint environments and how to backup site collections using a tool I wrote that enumerates the sites and creates a backup batch file that can be scheduled using Windows Scheduler.

(more…)