Note: This article is in draft yet and I’m still working on it.
Sometimes after moving SharePoint content (files, lists, sites, etc.) to a new place, you need to keep old links working. Sometimes you need to force users to use HTTPS instead of HTTP by redirecting them automatically. In these kinds of situation you can use the power of IIS URL Rewrite extension to achieve your goal.
In this walkthrough I’ll show you a way how you can keep old links to SharePoint content working after a migration of a site or part of its content to a new place. This solution can help you in different scenarios when you change the content URL, but don’t want to ask your users to update their links.
In my case, I used this approach when I did a migration of inherited SharePoint 2010 to a new server. During the migration there was an upgrade to SharePoint 2013 and total revision and reorganization of the content structure. A lot of files were moved to new libraries and folders, some department sites were split up, while others were combined. The main challenge in this migration was the strong requirement that all the old links should keep working. The requirement was fulfilled and by now it has already been working in production for about a year without any issues.
Some of you, probably, have already known that I took participation as a reviewer of a book related to SharePoint 2013 disaster recovery while it was preparing for the publishing. It appeared, that during this month I will use it as the main reference guide for my work.
I have just recorded a short screencast for the beginners in SharePoint which should help understand what is SkyDrive Pro and how to use it. Probably, it could be useful for some of you who don’t know what is SkyDrive Pro yet. Enjoy watching
Probably, some of you have already known about SharePoint Community and are already its members. Those of you who don’t know about it yet, should definitely at least take a look at it. It is a very fast growing community and it already has more than 3000 members. It has really nice articles, features and benefits.
One of the cool features I have been looking for since I started working on SharePoint was online chat with other SharePoint administrators and developers. This community has it! It is pretty active so you can talk with other SharePoint guys in real time!
Also it has a lot of benefits for members. Today, I was one of the lucky people and have won a prize. It is a book which was donated and written in part by Jasper Oosterveld. The book is called The SharePoint 2013 Handbook: An insight by the SharePoint community. I have not started to read it yet, but will definitely do that in a few days.
So, I invite you to join this awesome community, because it is really worth it!
I have experienced this issue several times on different farms. After some manipulations with the workflow using SharePoint Designer or a web browser, occasionally, it started to be impossible to open published workflow. The others workflows continued to work as expected, whereas when I tried to open the one that started to misbehave it showed the following error message “Failed to load the workflow definition for the workflow”.
Several days ago I finally moved my blog to a new domain. Now its main location is http://sp2013.pro. Old domain (http://sp2013-blog.com) and old direct links will be either accessible for about a year, but it is better to update bookmarks even now.
I have prepared quite a few interesting posts, but for a while they are only in my mind and in some pieces of code. I hope I’ll find some time to publish them soon. So, stay tuned!
Yesterday I stumbled into an issue. My custom task outcome of SPD 2013 workflow stopped to function properly. It set to default value regardless of the Task Outcome I set programmaticaly in my custom ASP.NET task form.
My task settings looked as follows:
But when I pressed “Reject” or “Approve” button in my form, my ApprovalOutcome variable set to “Approved”. When I changed Default Outcome to “Rejected” this variable set to “Rejected” regardless of pressed button.
Sometimes when you work on workflows in SharePoint Designer you can not publish it, because the Check for Errors fails with the following mesage: “The workflow contains errors, but they are not visible in the current view”
Usually in this case you really can’t see the place where the error is and it seems like everything is OK.
I spent some time to understand where the error is when I saw this error the first time. Most likely it is an issue in SPD; however, it is rather simple to overcome it and force SPD to show the place the error is.
The solution: you just have to save your workflow (by pressing Save button in the ribbon), close it and open it again (by selecting it in the Navigation\Workflows and pressing the “Edit workflow” link).
After that you should be able to see what fields are set incorrectly:
You can press Check for Errors button to highlight all the errors with the red color:
I stumbled into this moment several times after copying-pasting my workflow. It seems like this new feature works well in the most parts of the workflow, except the Transition to stage part. At least, in my cases after pasting I had to repair fields in the Transition to stage part only.