Showing posts with label upgrading. Show all posts
Showing posts with label upgrading. Show all posts

Sunday 7 March 2021

.NET versions no longer supported

Update 1 Feb 2022:  For new projects use .NET6 (Core) it needs VS2022.  Don't use any versions of .NET framework (last release was 4.8) or .NET standard (last release was 2.0).

Problem:  The client has several existing .NET applications/products.  These products are running on Azures Service Fabric, which has been developed over several years.  Service Fabric applications have various .NET core and .NET framework versions, and many of the apps have gone out of Microsoft support for the .NET version they are written on.

Initial Hypothesis:  We have .NET framework and .NET Core apps.  .NET Core 5.0 has dropped the "Core" part of the naming, so it is merely .NET 5.   .NET framework came first, and the last version was .NET framework 4.8.  .NET Core is the follow on and .NET Core 3.1 next version has the name chnge to .NET 5.0.  The "Core" part is dropped.  Lastly, .NET Standard is often used by software companies to write dll's. Only class libraries are allowed, but any .NET framework or .NET core projects can reference them.

  • .NET Framework - 4.8 was the latest release version
  • .NET Core became .NET - Last was 3.1 but renames to .NET 5 which is the latest version
  • .NET Standard - Class projects only

Proposed Resolution: My preference is to upgrade .NET core and .NET Framework separately as this is the lowest risk, most extended life with minimized cost. 

 .NET Core

For .NET Core apps, if less than .NET core 3.1 migrate the app to .NET 5.  .NET Core 3.1 don't upgrade.  Any other versions should be upgraded to .NET 5. 

Version

Release date

Released with

Latest update

Latest update date

Support ends[20]

.NET Core 1.0

2016-06-27[21]

Visual Studio 2015 Update 3

1.0.16

2019-05-14

June 27, 2019

.NET Core 1.1

2016-11-16[22]

Visual Studio 2017 Version 15.0

1.1.13

2019-05-14

June 27, 2019

.NET Core 2.0

2017-08-14[14]

Visual Studio 2017 Version 15.3

2.0.9

2018-07-10

October 1, 2018

.NET Core 2.1

2018-05-30[15]

Visual Studio 2017 Version 15.7

2.1.26 (LTS)

2021-03-09

August 21, 2021

.NET Core 2.2

2018-12-04[16]

Visual Studio 2019 Version 16.0

2.2.8

2019-11-19

December 23, 2019

.NET Core 3.0

2019-09-23[23]

Visual Studio 2019 Version 16.3

3.0.3

2020-02-18

March 3, 2020

.NET Core 3.1

2019-12-03[24]

Visual Studio 2019 Version 16.4

3.1.13 (LTS)

2021-03-09

December 3, 2022

.NET 5

2020-11-10[25]

Visual Studio 2019 Version 16.8

5.0.5

2021-04-06

3 months after .NET 6 release


 
.NET Framework

For .NET Framework, anything less than .NET Framework 3.5, move to 3.5.  3.5 Framework based apps can stay on 3.5.  For app using .NET Framework 4.0 to 4.5.1 upgrade to .NET framework 4.8.  For app using .NET 4.5.2 to 4.7, stay on their versions.

Version

Existing Application Support

Target New Applications?

1.x

out of support - migrate ASAP

out of support - do not target

2.x

out of support - migrate ASAP

out of support - do not target

3.x

out of support - migrate ASAP

out of support - do not target

3.5

 Operating System (until 2029) 

Operating System (until 2029) target with caution

4.0 to 4.5.1

out of support - migrate ASAP

out of support - do not target

4.5.2 to 4.7

⚠️Operating System (mixed) - review support policy of each version

Operating System (mixed) - target with caution

4.8

 Operating System (indefinite)

 Operating System (indefinite)


.NET Standard


Monday 24 March 2014

Installing CU1 for SharePoint 2013

Overview: I need to upgrade from SP2013 CU June 2013 to SP2013 SP1. 

Tip: SP1 does not require the March 2013 PU to be installed.  In my situation it was already installed.

Steps:
1.> Check there are no upgrades pending.
2.> Run the SP1 upgrade on each machine in the farm containing the SP binaries.
3.> Ensure the Upgrade is required PS>get-spserver $env:computername).NeedsUpgrade
if True on all SP machines (can also verify on a large farm using CA as shown below) then
4.> PS> psconfig.exe -cmd upgrade -inplace b2b -force  (This will upgrade the SharePoint databases and update the binaries on the 1st machine).
5.> Run psconfig on all the remaining SharePoint servers in the farm.

Result:  The farm should upgrade, my dev farms upgrade however my UAT and Prodcution farms did not complete the upgrade, the fix is shown below.

More Info:
http://blogs.msdn.com/b/sambetts/archive/2013/08/22/sharepoint-farm-patching-explained.aspx

***************

Problem:  The Usage and Health database cannot be in an AOAG when upgrading.
 ERR          Failed to upgrade SharePoint Products.
An exception of type System.Data.SqlClient.SqlException was thrown.  Additional exception information: The operation cannot be performed on database "SP_UsageAndHealth" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
ALTER DATABASE statement failed.
System.Data.SqlClient.SqlException (0x80131904): The operation cannot be performed on database "SP_UsageAndHealth" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
ALTER DATABASE statement failed.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler,


Tip: Any CU, PU or SP will not perform the upgrade if the Usage and Health SharePoint database is a AOAG database.  You need to remove the db and perform the upgrade.

Initial Hypothesis:  The error message is pretty clear that the problem is the UsageandHealth database can't be modified in the upgrade process if it is part of the availability group.  I use an aliase so I could repoint the aliase to the primary database do the upgrade and then update the SQL aliase back to point to the listerner or the approach I use is to remove the AOAG listener for the usage database, perform the upgrade to SP and readd the AOAG for the HealthandUsage database.

Resolution:
1.> "Remove the UsageAndHealth database from the Availability Group",

2.> Perform the SP1 upgrade
3.> Change the Recovery model to "FULL" and perform a Full backup.
4.> Add the database back in as part of the availability group.

***************

Problem: When running PSConfig to upgrade my SP2013 farm to include SP1, the upgrade fails and the PSConfigDiagnostic log informs me of the problem:
WRN Unable to create a Service Connection Point in the current Active Directory domain. Verify that the SharePoint container exists in the current domain and that you have rights to write to it.
Microsoft.SharePoint.SPException: The object LDAP://CN=Microsoft SharePoint Products,CN=System,DC=demo,DC=dev doesn't exist in the directory.
at Microsoft.SharePoint.Administration.SPServiceConnectionPoint.Ensure(String serviceBindingInformation)
at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run()






More Info
http://onpointwithsharepoint.blogspot.co.uk/2013/06/configuring-service-connection-points.html
http://sharepointfreshman.wordpress.com/2012/03/02/1-failed-to-add-the-service-connection-point-for-this-farm/
http://gallery.technet.microsoft.com/ScriptCenter/af31bded-f33f-4c38-a4e8-eaa2fab1c459/
http://blogs.technet.com/b/balasm/archive/2012/05/18/configuration-wizard-failed-microsoft-sharepoint-spexception-the-object-ldap-cn-microsoft-sharepoint-products-cn-system-dc-contoso-dc-com-dc-au-doesn-t-exist-in-the-directory.aspx

Saturday 25 February 2012

Quick Way to Verify your Build

Problem: Going to a new client you need to work out each of their enviroments, this can be done using CA, PowerShell and T-SQL.

Inital Hypothesis:  Create a PowerShell script that crawls and maps the farm, and outputs the results.  This should examine all the WFE and application servers and the SQL Servers.  If should report on the OS, SQL Server and SharePoint. 

Resolution:  Until someone builds a better flushed out script, I am looking at the local instance of SQL (default) and the SharePoint farm.  This script has been tested to run on a full standalone machine containing both SQL Server and SP2010.
Additional work could be done to crawl all servers in the farm and output the results.  As BGInfo gives the local admin all the network and OS data, this script does it for the application software.

Additional work to do to this script is to loop thru all the SQL instances remotely, display a report or even generate a nice diagram and potentially change the background screen save with all the information on the server containing Central Admin.

In the screen shot above: SQL Server build versions 10.50.2500.0 is SQL Server 2008 R2 SP1; SP2010 build version 14.0.6109.5002  is CU August 2011.
GetSPInfo.ps download.



Updated: 19 July 2012 - Add the line tot he script to show SQL 2012 under the version:
11 {[string]$SqlInfo.SQL_Version = "SQL Server 2012"}

Updated: 24/02/2012 - I had problem in UAT where I was getting stange behaviour and I releaised somebody had changed the time on one of 10 SharePoint servers causing me problems.  The script below verifies the TimeZone for servers in your farm. 
 
 
More Info:
SP2010 build number by Dave Coleman.