Whilst Intranets by definition are inaccessible to the outside world (and are reliant on the IT infrastructure for this), it is still often desirable for companies to create areas within an Intranet that certain departments may not want accessible to all employees. For example, the Finance department may want to have some information available, but the company employs a number of contractors that have access to their network. There can be the need, therefore, to secure certain areas to ensure only certain groups of people have access.
Authoring new content for the Intranet often takes place directly on the site itself. There are typically Intranet Administrators who look after the Intranet at the global/corporate level, these are normally Communications or Marketing staff. Each department within the organisation will have their own Content Owners/Managers who will “own” and author their content on the Intranet.
Sophisticated Intranet platforms today will provide a security infrastructure out of the box to easily allow Intranet managers to provide the right level of access to areas for the users who require it. The security infrastructure of an Intranet platform may allow for use of areas as an Extranet – this being defined as the sharing of content amongst a well-defined group that crosses enterprise boundaries. This will allow tightly controlled access to certain areas of the site to allow people external to the business, such as partners or contractors, to perform certain tasks, such as logging time in a timesheet system. SharePoint provides advanced security and permissions functionality out of the box which is easy to manage, meaning IT are not always required to manage permissions within the Intranet.
For more on the security measures and practicalities involved in implementing an Intranet, check out our free Intranets Explained guide here.
Since SharePoint was first introduced in 2001, content types have been a key feature in the way it is used to managed documents and files. A content type combines important information such as metadata (a summary of the content), how it should behave, it’s workflow and other settings to be applied to a category of items or documents.
As an example, we could define a content type “Invoice”; this could then be applied to all invoice documents within a SharePoint library. Within this content type, we could have the following attributes:
A behaviour requirement to automatically display the Document Information Panel when a new file of this content type is created to input the required metadata
An Information Management policy detailing the retention policy
SharePoint ships with a number of useful default content types. Many of these contain similar properties to file types that you would store on your own computer, such as the “digital assets” content types – audio, video and image. These content types contain information about the title, publisher, length (for audio and video) and date of creation. There are also document and list content types for basic pages, forms, blog posts and announcements.
Whilst the default content types are sufficient for many SharePoint users, it may be necessary for your organisation to create custom content types. This is useful for company reports, sales proposals, case studies and other specialised content. This is most easily achieved by editing an existing content type from one of the large collection of pre-defined site content types in the Web Designer Gallery. It is also possible to create a custom content type from scratch in the Web Designer Gallery by setting a parent content type, for example, “Digital Asset”.
Content types are defined for a site and will apply within the site and its subsites. However, if you want a particular content type to be used across your organisation you may want to publish it on multiple sites or site collections. Using a Managed Metadata service in SharePoint allows you to publish content type to specified sites, known as “subscriber sites”. For more on content type publishing, read Microsoft’s guide here.
Flexible work arrangements have long been a feature in the workplace, but as more collaboration technologies move to the cloud, it’s becoming increasingly common for workers to work from home. A recent report by the TUC shows that the number of employees choosing to ditch the office continues to soar, with a 20% increase in home-workers in the last decade. According to Phil Flaxton, Chief Executive of WorkWiseUK and the organiser of National Work from Home Day:
“Increasing mobility and technology is shifting the acceptance or need for traditional office based, 9-5 work patterns, to be replaced by more home-based, flexible ways and periods of work”
Not only has this shift increased the options available to workers, but according to data published by Gallop, the added flexibility has dramatically impacted employee engagement, with the most productive workers reported to be spending just one day a week in the office.
Source: Gallup State of the American Workplace Report 2013
So it’s clear that the ability to spend time working outside of the office environment is not only desirable for employees, it brings numerous benefits for organisations. But companies need to consider their readiness to adopt such working practices. With this in mind, how can employers adapt their work practices to suit the growing trend of flexibility?
Within every organisation, there are a variety of ways departments communicate with each other. Whether it’s with instant messaging, teleconferencing, email or carrier pigeon, when you throw long distance in the mix, it can be overwhelming. Despite the number of tools claiming to be able to cover all the niche requirements of collaboration between teams, they usually end up just adding one more source of information to the already overcrowded collection. Instead of trying to cover all bases with one solution, it’s becoming more desirable and realistic to use tools that integrate into a single platform. Microsoft’s offerings in productivity software are ever-growing, and their ability to work with each other is unrivalled. For applications with less cross-compatibility, apps such as Flow allow processes to be linked together; for example, you can use Flow to get a push notification when you receive an email from your boss.
As the amount of data storage required by businesses increases exponentially, it’s more important than ever to have files stored in one central location, accessible from anywhere. It’s no longer enough to hold information on a physical hard drive – it’s expensive, insecure and it relies on the user being in the same location as the storage device. For maximum productivity, your employees need to be able to find the information they need in one place, without laborious searching of archives and trawling through dead links. A digital workplace allows information storing, sharing and collaborative working in a centralised location, and can also act as a training platform with access to internal resources and how-to guides.
With the ability to access sensitive data from any location, companies have reduced control over the security measures in place when staff work from home. Risks vary from the loss of files that have not been backed up, the theft of passwords or the computer itself being compromised. For these reasons, it’s essential that there is a protocol in place that establishes the rules for working from home or outside the office. Using cloud-based platforms – such as Microsoft Office 365 – allows users to access Office applications, email, calendars and file sharing via a secure connection, with no data being stored on the employee’s own computer.
With the trend of working from home looking set to last, it’s vital that businesses invest in the technology that allows their workers to enjoy the benefits of flexible working. For more information on strategies to improve your businesses ability to allow working from home, check out our webinar on the top ten benefits an Intranet can bring to your business.
Quite often you may wish to start a SharePoint Search content crawl on demand, without waiting for the next scheduled crawl to start. You may still be running SharePoint Server 2010, or not able (or willing) to run a continuous crawl of your content.
To make your job that little bit quicker when it comes to starting a Search Crawl, you can easily start either Incremental or Full Crawls via PowerShell.
Simply retrieve the Content Source that you want to crawl, then invoke the appropriate method.
$cs = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication "Search Service Application" -Identity "Local SharePoint Sites"
# This method starts a full crawl
# This method starts an incremental crawl
# Do this to stop any currently running crawls
# This property returns the status of your crawl
Obviously, change the SearchApplication parameter to match the name of your search application, and the “Identity” parameter to match the name of the specific Content Source you want to crawl.
You can wrap up all of the PowerShell lines that you need to kick off the crawl you want into a text file with the extension of “.ps1” and invoke from a SharePoint Administration Shell prompt whenever you need to!
If you look through your SharePoint ULS logs during the development of server-side code and you spot the warning:
An SPRequest object was not disposed before the end of this thread. To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it.
Then there’s a chance you haven’t followed Microsoft’s best practices around disposal of unmanaged resources in the C# SharePoint Server Side Object Model.
Going solely by the information in ULS doesn’t immediately show you where your SPSite or SPWeb was instantiated. As the warning states, you need to enable SPReqest Allocation Callstacks to see full stack traces of your code to see where you need to fix SPRequest issues.
The following PowerShell snippet will do just that:
Of course, as you develop you can use static analysis tools such as SPCAF from Rencore to make sure you’re following the best practice for object disposal as you code.
You may also notice that sometimes you will see this error when performing valid API tasks where you do not necessarily create the SPWeb or SPSite objects yourself. I’ve noticed this in particular with the Taxonomy API. I found these to be acceptable exceptions when analysing the ULS log for these warnings, as the code that raises the warning is deep within assemblies that are maintained by Microsoft, and the warnings may disappear over time with service pack releases.