On 2/23/2017 Microsoft announced the General Availability release of the SharePoint Framework to Office 365 tenancies. This is a very exciting time for SharePoint developers as the SharePoint Framework allows us to take advantage of development tools and processes that truly enhance the developer experience. Having worked with multiple client side development toolkits in the past I can honestly say “It’s about time!”.
Some great news for the guys and gals managing small scale SharePoint 2016 Farms – MinRole installation just got a lot more feasible.
When MinRole was originally announced, I looked at it as a great justification to make the move to SharePoint 2016. Imagine, no longer needing to take down production SharePoint environments in order to apply patches… Sign me up!
Unfortunately, when the requirements came out for the MinRole setup, many organizations could not justify setting up 8 servers to create a High Availability SharePoint Farm.
Microsoft responded to customer feedback today at Ignite in a big way with the announcement that Feature Pack 1 for SharePoint 2016 (available in November) will include an option for creating a High Availability SharePoint 2016 Farm with just 4 servers. By combining the Web Front End and Distributed Cache roles as well as the Application and Search roles Microsoft is really opening the door for small/mid organizations to treat their SharePoint 2016 environments as “first class citizens”.
I am truly excited by this announcement. As a consultant I often times find myself struggling to keep the customer happy with the overall cost of a system while still following best practices. This enhancement not only makes small to mid-size SharePoint 2016 Farm Administrators lives easier, it makes mine a bit easier too.
For a full listing of details on Feature Pack 1 please reference the Office blog Announcing Feature Pack 1 for SharePoint Server 2016—cloud-born and future-proof
I have a client that needs to log any interactions with their customers in SharePoint. This client is proficient enough with SharePoint that they feel perfectly comfortable modifying lists in order to add or remove fields to accommodate their needs without having to go through us. They are regularly adding new fields to this log list in order to capture some new piece of relevant information that it was decided they needed. This is important background because when they approached me to create a way for them to generate multiple log entries from one “New Item” SharePoint List Form, I knew I couldn’t just create a custom “New Item” form to accomplish this or they would lose the ability to add new fields without having to either modify this custom “New Item” form, or involve us to make those modifications.
So I had to come up with a solution that would retain the standard “New Item” form (so any fields added/removed from the list would be reflected in the form) but would allow for the user to create an entry in their logs for every customer selected in the form.
I was recently tasked with creating an effective means of tracking/reporting on project tasks in SharePoint Online. Based on the requirements I setup everything “out of the box” to show what could be accomplished by using simply using Content Types, Site Columns, Managed Properties and Search. The client liked the outcome but didn’t necessarily love it. Search API to the rescue. More…
I have a client that has over 50 subsites of the root site in a SharePoint site collection that are all pretty much the same. There’s a site for each county in the client’s state, each one with web parts to show some data from the root site that’s relevant to that specific county (contacts’ information, documents, that kind of thing). Whenever they wanted to make a change to, say, the contacts web part for these county site, they had to modify over fifty copies of the same web part. Tedious to say the least. After a few rounds of making these kind of repetitious modifications it was decided that I would need to come up with a solution to make managing this stuff much easier.
So I did.
I recently needed to implement a custom event receiver on a document library with Incoming E-Mail enabled so that I could extract .zip file attachments from the email and put some metadata on the documents as they entered the library. I had set up the Incoming E-Mail on the library and had tested that it was properly receiving emails/attachments, which all worked just fine.
Then I created my event receiver.
We’ve been working with documents sets for a couple of years now. Document sets are a great way to group the different types of documents that we create to combine into one Statement of Work that is delivered to our clients. It is also a great place to store any and all of the emails and documents that the client may give to us to refer to as we put together our SOW.
Figuring this out took me longer than I expected it would. Attachments are not included as a column in a SharePoint list, but are saved in a folder that is named after the id of the item you attached the file to.