SharePoint 2013 Archives - Applied Information Sciences

@clinterich

During a recent consulting engagement with an enterprise customer, we resolved a strange issue with search in SharePoint 2013. I wanted to create this blog post as I was unable to find another source with the steps to resolve the behavior. I hope this will help anyone encountering this issue and save you days of troubleshooting! Read More…

Brent Wodicka

@bwodicka

If you’ve ever had the need to add document management capabilities for your entities in CRM, you already know that CRM 2013 and CRM online rely on SharePoint for this functionality. This out of the box integration point is well documented and available for configuration in the CRM administrative interface. When set up, users can create, upload, view and delete documents in SharePoint locations that correspond to entity instances in CRM.

This post will discuss a different integration point – using search in SharePoint 2013 to expose CRM entity data. When setup properly, SharePoint 2013 can provide a robust, enterprise level search capability that can be tailored to your needs. Also, it seems to fill a current functionality gap in CRM that often requires a third party tool. Granted, you will need SharePoint 2013 Enterprise to realize this setup, but if this is available to you there should be no need to look anywhere else for search. Read More…

Chris Hettinger

@ChrisHettinger1

Recently, I encountered an issue with SharePoint 2013 search crawls where .pdf files smaller than 1 MB reported a warning: “The item has been truncated in the index because it exceeds the maximum size”. The default MaxDownLoadSize for documents in SharePoint is 64MB, which was more than enough the handle these relatively small .pdf files.

After I reached out to some co-workers; one suggested that the error might be a false-positive and the entire document had been crawled. I tested this by first searching for words at the end of the document and no matches were found; this would be expected if it were truncated. Next, I tried searching for text in the middle of the document, no matches were found either. I thought it must have truncated a lot of text and tried searching for text contained at the very beginning of the document. No results were found! So when the warning said it truncated the item, it had truncated the whole document. Read More…

Sam Larko

@SPSamL

SharePoint Server 2013 offers a completely new architecture for Workflow utilizing Workflow Foundation 4.5. I’ve already covered the high-level changes in a previous post called “What Changed in SharePoint 2013 Workflow? Pretty Much Everything” and discussed how a SharePoint 2010 Workflow project would be designed differently in my post titled “Redesigning a SharePoint 2010 Workflow Project for SharePoint 2013.” Both of these posts discuss the new reliance on web services for data in SharePoint Workflow. While it’s obvious that Visual Studio workflows would interact with web services, SharePoint Designer 2013 offers web service communication, as well. This post will detail the new actions available in SharePoint Designer 2013 for interacting with web services and how to use them. Read More…

Christine Rabine

Change Data Views from Boring to Flashy

Data, data, data… Working professionals are inundated with data. Anything that makes that data easier to understand, analyze, and compare is a welcome breath of fresh air. Why snooze over a boring and static table when you can view key metrics at-a-glance in a snazzy chart?

Many SharePoint sites are used for managing internal business processes where users store and analyze data. SharePoint 2013 makes it easy to store data in lists, and view that data in a team site, but usually that data is shown in a basic table view. Read More…

Scott Hoag

@ciphertxt

In the world of SharePoint upgrades and migrations, a number of terms are thrown around and often used interchangeably. This post outlines several key terms that will be surfaced throughout a three-part series on upgrade/migration strategies for SharePoint 2013. If you would like to jump to another post, use the links below:

Part 1 – Definitions (this post)
Part 2 – Considerations Outside of SharePoint (Coming soon)
Part 3 – Diving into Database Attach (Coming soon)

In past revisions of SharePoint, we had multiple ways to upgrade our farms (and the content within them) to the latest version using the tooling Microsoft provides. Over the years, Microsoft used a number of terms related to the types of upgrade available:

In-place upgrade – Often considered the easiest approach, but the most risky. The setup of the new system is performed on existing hardware and servers.
Gradual upgrade – Allows for a side-by-side installation of the old and new versions of SharePoint.
Database attach/migration – Allows for the installation and configuration of an entirely new environment where content is first migrated, and then upgraded to the desired state.

As SharePoint matured, the number of available upgrade options dwindled. For instance, in an upgrade from SharePoint Portal Server 2003 to Office SharePoint Server 2007, we could follow any one of the three upgrade paths noted above to reach our desired end state. In an upgrade of Office SharePoint Server 2007 to SharePoint Server 2010 we still had two paths available: the in-place upgrade and the database attach approach. For SharePoint 2013, we’re left with just the database attach approach.

Before we dive further into the database attach upgrade scenario, it’s helpful to take a step back and establish a common language as we discuss the upgrade process. Read More…

Darrin Brandon

In a recent blog post, I walked through setting up a SharePoint 2013 development environment in the cloud. After doing that, the next most logical step was to start building apps. But that meant that I would have to understand what a SharePoint app really was and how it differed from SharePoint 2010 development. I mean sure, I could bang out the typical “Hello World” app, but to do anything meaningful, I needed to dig a little deeper.

Apps vs. Solutions

An app for SharePoint is a stand-alone, self-contained piece of functionality that extends the features and capabilities of a SharePoint site. Apps can bring together the best of both worlds; modern web technologies and all the familiar pieces of SharePoint. On top of that, users can discover and download apps on their own from the public Office Store or from their organization’s private App Catalog. In contrast, a solution is used to customize or enhance SharePoint sites and needs a farm administrator to deploy, manage and remove.

Why Apps?

The first question that I asked myself was why would you use an app? I would assume that the answer to this question might depend on who you polled, but as a developer, I am extremely excited that I can now leverage all of the exciting things that my “non-SharePoint” counterparts have been doing for quite some time. In my opinion, this paradigm shift is a smart move by Microsoft, and will go a long way in attracting more developers to the platform.

Read More…

Anthony Mudd

I recently needed to make several web.config changes to our production SharePoint 2010 web farm. Making all of these modifications manually would have been tedious and would have left a lot of room for error. After doing some research to find a better way, I discovered the SPWebConfigModification class in the Microsoft.SharePoint.Administration namespace.

This is basically a collection of changes to be made to web.config files that can be stored and then applied to all web front-end servers in a farm. This class is available with SharePoint 2010 and 2013. Unfortunately, the class is poorly documented so I had some trouble figuring out how to use it. You could write a console application to use the SPWebConfigModification class or you could use a feature receiver, but I found that the easiest approach was to just use it with PowerShell. After some trial and error, I came up with the following four PowerShell scripts that can be reused to read, add, remove, and completely clear the SPWebConfigModifications on the server. Read More…

Vinita Agrawal

@agrawal7vinita

SharePoint 2013 introduced a ton of new features for the end user. It also brought about a lot of changes for SharePoint developers, particularly in terms of the new SharePoint App Model. I’ve been a core SharePoint developer for seven years now, through both the 2007 and 2010 releases, and so I thought it might be beneficial to share some lessons learned from my own transition from core SharePoint developer to a SharePoint 2013 app programmer.

My previous experiences with SharePoint development focused heavily on MOSS code with workflows, InfoPath, Lists, Content Types and developing front end applications using these features. I had almost no JavaScript experience, especially Async programming, and no clue what SharePoint apps are or what they look like.

My two immediate realizations when faced with SharePoint 2013 were that:

I had to learn lot of new terms: SharePoint Hosted, Provider Hosted, Auto Hosted, On Prem, O365, Host web, App web and many more.
Your working hand is tied behind your back and your head hurts more than ever before, because in the realm of client-side coding you have to think differently, about a 180 degree twist. It gets better after a week or two of JavaScript immersion.

For my current SharePoint 2013 project, we are using Durandal and RequireJs for creating user interface screens and the SharePoint Javascript object model (JSOM) for backend service code. You don’t need Durandal and RequireJs to do SharePoint 2013 programming, but we chose them for creating user screens as single page application. Read More…

Sam Larko

@SPSamL

Workflow in SharePoint 2013 has undergone quite the architectural change from its SharePoint 2010 ancestor. I documented many of the major changes in a previous blog post, “What Changed in SharePoint 2013 Workflow? Pretty Much Everything.” While SharePoint 2013 is backwards-compatible with SharePoint 2010 workflows, you may decide that the benefits of the new design are needed. The purpose of this post is to illustrate the new considerations you’ll need to keep in mind when targeting SharePoint 2013 workflows. The SharePoint 2010 project we’ll use for this example is the one from my very first AIS blog post, “Developing Multi-Tiered Solutions for SharePoint.”

Web API Methods Mockup screen shot — Figure 1 - Sample WebAPI methods for Section Document Merge and Post-Merge Actions.

In our example project there are actually two workflows, SectionDocumentApprovalState (SDAS) and MasterDocumentApproval (MDA). The MDA checks if the various SDAS-related sections have been merged and finalized, then notifies specific users for approval of the final document. An instance of SDAS is created for each section, created from the Master Document that monitors the editing and approval of the specific section. We’ll focus on just the SDAS workflow. In the previous post, I referred to the workflows as being part of the Presentation Layer and the custom code called into the Business Layer. Both of these layers will change in a SharePoint 2013 workflow solution.

BlogPosts tagged with “SharePoint 2013”

Change Data Views from Boring to Flashy