SharePoint2010 Archives - Daniel Glenn

SharePoint Workflows are Dead (Almost)

Daniel — Mon, 20 Jul 2020 04:34:22 +0000

The end of support for “SharePoint 2010 workflows” in Microsoft 365 will be November 1st, 2020. The title of the blog post, Support update for SharePoint 2010 workflows in Microsoft 365, doesn't make it clear, but we are seeing the beginning of the end for SharePoint workflows in SharePoint Online. This is truly the end of SharePoint workflow. End of SharePoint Workflow It isn't a surprise that Microsoft is moving to not support native workflows in SharePoint. At Microsoft's Ignite conference in 2016, Microsoft announced that support for SharePoint Designer workflows (and InfoPath forms) in SharePoint Server (on-premises) would in time not be supported. The end of support date was stated to be until 2026. However, the key to those announcements and subsequent blog posts was that they were talking about the on-premises versions of SharePoint Server. There has never been a promise to support older versions of workflows in SharePoint Online for that period of time. There also has never been a timeline released when SharePoint workflows would stop being supported in SharePoint Online – until now. At time of publication, the older blog posts announcing the on-premises changes could not be located. What was assumed at the time, though, was that Microsoft would give ample amount of notice when existing workflows would be removed from SharePoint Online. SharePoint 2010 Workflows have been deprecated If you received this warning when you looked at your workflow page, then your tenant has already been affected. So what is actually being changed? Read on. What Exactly is Being Removed There is some confusion because the specific workflow engine being removed is being called “SharePoint 2010”. However, this isn't a signal of the version of SharePoint itself, but the version of the workflow engine. There are two different categories of workflows that are included in the retirement: 1) out of the box workflows that come with SharePoint and 2) workflows created using SharePoint Designer. Out of the Box Workflows There are several out of the box (OOTB) workflows that have been available to configure in document libraries and lists for many past versions of SharePoint. OOTB workflows are easily created and maintained within the SharePoint user interface (UI). These workflows include Approval, Collect Feedback, Collect Signatures, Disposition Approval, and Three-state. These workflows are used widely by power users, developers, and site users. They are configured easily in the UI and because they are OOTB, don't usually fail because of a step that has been configured incorrectly. 2010 Workflows Created with SharePoint Designer The other category of workflows that will be disabled are those created with SharePoint Designer (SPD). SPD is a free application that has been used by power users, administrators, and developers around the world to edit SharePoint pages, modify settings, and create powerful workflows. Both SharePoint Designer 2010 and SharePoint Designer 2013 versions can create 2010 workflows – the workflow author chooses what engine when they first create the workflow. When Will SharePoint Workflows be Disabled? As reported in the blog announcement, there are several dates to keep in mind. August 1st, 2020 – after August 1st, any new Microsoft 365 tenants will have 2010 workflows disabled. November 1st, 2020 – on November 1st, Microsoft will begin disabling all 2010 workflows on all sites. Also in November 2020, 2013 workflows will be disabled by default for any newly created Microsoft 365 tenants. Are 2013 Workflows Being Removed? If this is the end of SharePoint workflow, are 2013 workflows being removed too? Starting in November 2020, Microsoft will disable 2013 workflows by default for any newly created tenants. However, administrators will be able to turn it back on via PowerShell. Microsoft is not giving a timeframe for when 2013 workflows will be removed just like 2010 workflows. They will be ‘deprecated' in November 2020, which is the first step in saying they will be removed in the future. It is my opinion that if the process of 2010 workflows goes smoothly, then the 2013 workflows will not be far behind. So what do I mean by ‘smoothly'? My first requirement for this to be ‘smooth' is if customers don't complain too much. Some customers say less than 4 months notice is far too little time. This also comes during a global pandemic that has organization budgets stretched thin. There is a UserVoice created with over 1,000 votes and if you feel the notice of change is too short, you can vote there. My second requirement for this to be ‘smooth' is if removing the workflows is successfully performed and happens without causing issues for sites. What Do We Do Now? A good resource to help you get started in the process is Microsoft's support article SharePoint 2010 workflow retirement. The page lists how to identify your workflows, and says you should recreate the workflows in Power Automate. The first step will be to identify the workflows you have running on your sites using the SharePoint modernization scanner. Second, organizations need to identify which of the workflows in their environment are being used and should be recreated in Power Automate. This second step might take some time if you have been using SharePoint for many business processes in your environment. The third step is to then recreate the workflows in Power Automate. There are five points to go into this process. Working with the owners to recreate the workflow Incorporating any process improvements Identifying gaps in Power Automate functionality that might need more complex processes Testing Running a change management program to roll out the new workflows That could be a tremendous amount of work. You need to know if you can make progress during the 3.5 months you have before your workflows are disabled. Need Help? If you find that you need some help with any of the steps above to meet the deadline, make sure you contact me! Fill-out my contact form and let me help.

The post SharePoint Workflows are Dead (Almost) appeared first on Daniel Glenn.

SharePoint 2010 Site Experience With SharePoint 2016

Daniel — Wed, 15 Jun 2016 22:49:21 +0000

While testing an upgrade today, I was reminded of a requirement when upgrading to SharePoint 2016 using the database attach method – you must upgrade all site collections to the SharePoint 2013 experience before you attempt to attach the database to a SharePoint 2016 farm. My test today is using a SharePoint 2010 content database and attempting an upgrade to SharePoint 2016. I first performed a database attach upgrade with a SharePoint 2013 farm, then performed the Test-SPContentDatabase PowerShell command on the database from my SharePoint 2016 farm. It is important to notice that the LegacySiteDetected error shown above is an UpgradeBlocking error, meaning the upgrade will fail if you proceed. Following the direction listed in the Remedy section will fix the issue, but it does require working in the SharePoint 2013 farm to upgrade the site's experience to 2013. More information on how to perform that operation can be found here: Expand Upgrade a site collection to SharePoint 2013 [TechNet]

The post SharePoint 2010 Site Experience With SharePoint 2016 appeared first on Daniel Glenn.

Upgrade SharePoint 2010 to 2016 Release Candidate

Daniel — Fri, 04 Mar 2016 16:58:47 +0000

It is a frequent question – can I skip a SharePoint version when upgrading? For example can I do a direct upgrade from SharePoint Server 2007 to 2013? The answer is no, you can't without having to use a migration product – which isn't really “upgrading.” The path to upgrade SharePoint 2007 to 2013 includes an upgrade to SharePoint 2010 first. In March of 2015, Bill Baer, Senior Product Marketing Manager at Microsoft, asked if there was any demand for skipping ahead when doing a SharePoint upgrade (a.k.a. N-2 upgrade). #SharePoint question…if you could N-2 upgrade would you? I.e. 2010 > 2016 without stopping at 2013 first… — Bill Baer (@williambaer) March 4, 2015 My response was similar to many other SharePoint administrators and architects: Yes! Absolutely! I recently decided to give it a shot – upgrade a SharePoint 2010 site collection via database upgrade to SharePoint Server 2016 Release Candidate (RC). As of this post's writing, SharePoint 2016 has not been released to production (RTM), but since we have been told the RC is close to the what will be delivered in RTM, it would be a good trial. I installed Service Pack 2 and the December 2015 CU to my 2010 farm and after the typical issues, I was ready to go. I think I would have been disappointed if it ended any other way #SharePoint 2010 #Patching#Failpic.twitter.com/pDeLqFS20K — Daniel Glenn (@DanielGlenn) March 3, 2016 I took a backup of the 2010 content database and restored it as a new database appropriately named SP10_to_SP16RC_Content. On my SharePoint 2016 RC server, I performed a Test-SPContentDatabase Powershell call on the database. The result: Lots of red text! It appears the test failed when seeing a table column name ‘PlaformVersion'. So, from this, we can gather that the upgrade will fail. Just to confirm, I went ahead with the upgrade. SharePoint Server 2016 Release Candidate will not upgrade a SharePoint 2010 database via the database attach method. The database version required, as noted in the error message, is 15.0.4420.1017 – that's SharePoint 2013 RTM. To upgrade to 2016 RC, you will need to first upgrade the 2010 database to 2013, then you will be able to go to 2016 RC.

The post Upgrade SharePoint 2010 to 2016 Release Candidate appeared first on Daniel Glenn.

SharePoint 2010 Updates and 503 Error

Daniel — Tue, 06 Mar 2012 15:10:00 +0000

Today I updated a SharePoint Server 2010 test virtual machine with service pack 1 (SP1; Foundation and Server) and the August 2011 cumulative updates for SharePoint Foundation and SharePoint Server. I ran the SharePoint configuration wizard after installing all the updates. When I rebooted the server (suggested when encountering the User Profile sync problem after applying the patches) and tried to open one of the team sites, I received a 503 Service Unavailable error (as shown in the picture below). Service Unavailable – HTTP Error 503. The service is unavailable. Once I got over the “what did I do??!?” moment, I of course recognized this as an IIS error, not a SharePoint error. I opened the Internet Information Services (IIS) Manager MMC and noticed that none of the SharePoint Application Pools were running. After starting all the needed Application Pools, everything is back to normal.

The post SharePoint 2010 Updates and 503 Error appeared first on Daniel Glenn.

Error Connecting to Database Server

Daniel — Thu, 18 Aug 2011 21:15:00 +0000

I recently setup yet another SharePoint farm (this time using virtual machines) and ran into a problem that happens all too often. The scenario is this: I setup MS SQL server in preparation for getting SharePoint installed on a separate server. After setting up your service accounts in Active Directory and installing MS SQL on Server1, I set off installing SharePoint on Server2. When I got to the screen in the Specify Configuration Database Settings within the SharePoint configuration wizard, I received the following error: Cannot connect to database master at SQL server at ServerName. The database might not exist, or the current user does not have permission to connect to it. Knowing the database ‘master’ did exist, I setout to solve the “current user does not have permission” issue. I opened the SQL Management Studio and checked to make sure my account had permission to connect. I checked the permissions for the service account and everything looked good. So, what’s going on?!? Since I don’t follow a setup script anymore (I have done this hundreds of times, so I know what I am doing, right?), I had forgotten one step. MS SQL listens for incoming traffic on port 1433. When setting up your SQL server, you have to make sure you create a firewall rule to allow that incoming port. This is elementary and I should have remembered this step, but no one is perfect, right? So, I opened Windows Firewall (if you are using a different firewall product, the steps should be similar). I selected Inbound Rules in the left window and then chose New Rule… from the Actions menu on the right. Select Port for the type of rule you want to create, click Next, and then type in 1433 in the port field.Click Next and then select to Allow the connection. Go through the rest of the wizard by clicking Next and filling in the appropriate content. Again, this is not rocket science, but I hope this information can be helpful to the next person who forgets the important step of allowing inbound connections to their SQL server!

The post Error Connecting to Database Server appeared first on Daniel Glenn.