SharePoint

I’ve been working with SPFx for SharePoint Online for quite a while and have done numerous client projects for it but recently I’ve been asked to create a few SPFx web parts that would work on both SharePoint Online (SPO) and SharePoint 2019 (SP2019).

There are many challenges when migrating from SharePoint on-premises to SharePoint Online and one of the more common ones that I’ve encountered is handling email enabled libraries. These are libraries in SharePoint on-premises which are configured to allow a user to send an email with an attachment to a specified email address and the attachment is then stored in the library as a file.

Have you ever been looking through the SharePoint ULS logs trying to troubleshoot one issue or another and come across entries such as this: [Forced due to logging gap, Original Level: <TraceLevel>] <Some message> {0} I was recently working with a client who noticed an message like this in the ULS logs and was baffled by the fact that the {0} was not being replaced with the relevant data referred to in the message text.

So today I was doing some SharePoint 2013 app development against my Office 365 SharePoint 2013 tenant and I needed to view the HTTP traffic from the site in order to troubleshoot some issues I was having and I stumbled across something I found very interesting when I looked at the header details in Fiddler:

First off I want to clarify that the subject of this post is not my idea as it is something that my friend Roman Kobzarev put together for his company and I merely assisted with getting the code to work.

I recently published a post detailing the SharePoint 2010 SP1 PowerShell changes and, in that post, I mentioned that I was probably going to detail the API changes. Well, here they are.

With SharePoint 2010 we now have the ability to allow SharePoint to manage various service accounts thus foregoing the need to have IT administrators manually manage password changes. This new feature is a great benefit to SharePoint administrators and security conscious admins in general as it allows us to easily enforce our corporate security policies by changing these passwords on a schedule, and the administrators don’t even know what the password is so the likelihood of a compromise due to a disgruntled admin, though not eliminated, is somewhat reduced.

I, along with Paul Stork, recently gave a SharePoint 2010 deployment webcast where we discussed, among other things, Service Applications and some of the considerations that must be taken into account when planning your deployment strategy.

A lot of people that are using SharePoint 2007 (WSS or MOSS) for collaboration have either enabled self service site creation in which they allow their end-users to create a page using the scsignup.

I was working on a project recently where I had to deploy a settings file to the root of my web applications folder (where the web.config file resides). If you’ve ever had to do something like this before then you know that you cannot do this declaratively using the WSP’s Solution schema.