I am looking to patch my current install of Azure DevOps Server and have been looking for the numerical release version of the different patches/installs for Azure DevOps Server so I can determine the new changes that are coming through (or if a patch is even needed). All I can find (and feeling pretty stupid for it) are the names of each the installs/patches such as 'Azure DevOps Server 2019 Patch 1 Release Date: April 9, 2019' or the latest version, 'Azure DevOps Server 2019 Update 1.1 Patch 2 Release Date: April 14, 2020'.
My current installation is 17.153.29207.5 (AzureDevOps2019.Update1) which I found in the Azure DevOps Server Administration Console. I can speculate that Update1 might refer to the release, 'Azure DevOps Server 2019 Update 1 Release Date: August 20, 2019' but realistically, Update could have many different interpretations.I was hoping to find the actual version number to guarrantee which version I am actually upgrading to.
Does any one have any ideas?
You could download the installation file (.exe), then check details of that file: Right click the file > Properties > Details > Check Product version.
This article may benefit you: Azure DevOps Server 2019 Update 1 Release Notes
Related
We recently updated our production SQL Server 2016 Enterprise instance from SP1 to SP2. We are currently on version 13.0.5026. Prior to the upgrade, a user with connect rights to SSISDB and proper rights on the Integration Services Catalog folder could deploy an ISPAC file successfully.
After the upgrade, the same users can still deploy to the SSISDB, but when you execute the .DTSX, the script task inside fails validation. If I deploy the exact same ISPAC as a sysadmin, there's no issue. The usual solution I've seen is to confirm that SSDT Configuration Properties are set to SQL Server 2016. We have verified this is set correctly prior to building the ISPAC.
I saw a similar issue when migrating from SQL Server 2014 to 2016 a couple years back, but the solution at that time was to give the Proxy account that runs the package modify rights to the C:\Windows\Temp folder so it can generate temp files. This new issue is hard to pin down, and I don't want to give out sysadmin just so others can do the simple deployment steps.
Any thoughts or suggestions are appreciated.
*******Update/edit************:
The server has a SQL Server 2016 deployment tool located under SQL Server/130/DTS/Binn - ISDeploymentWizard.exe. This deployment tool works. There is another identical wizard under the 140/DTS/Binn location, same name but 1 KB larger (assuming this is because SSMS is a separate install now, and I installed latest and greatest on server). This one fails deployment. I'm banging my head against the wall as to why one works but the other doesn't. Locally we all use SSMS 2017, and with that we get the 140/DTS/Binn ISDeployment file, not the 130 (since that's SQL Server 2016 and we're using SSMS 2017, which I thought was backwards compatible). Either way, this problem just started occurring and we've been on the same version of SSMS for a few months.
Image of the Execution information report from SSMS
Had resolved a similar issue with C# scripts recently. In short: don't use 140 version of ISDeploymentWizard.exe with MS SQL 2016. It apparently mangles something in C# code, or components' properties, and 2016 runtime stops recognising them.
In my case, a package with C# script source has started to throw the following error during the validation phase:
Error: Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismatchException:
The version of C# source component name is not compatible with this
version of the DataFlow. [[The version or pipeline version or both for
the specified component is higher than the current version. This
package was probably created on a new version of DTS or the component
than is installed on the current PC.]]
at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostCheckAndPerformUpgrade(IDTSManagedComponentWrapper100
wrapper, Int32 lPipelineVersion)
The first comment here has helped me to ultimately identify the cause.
I had restore TFS database 2015(SQL 2014) to 2018(SQL 2017) successfully. and remapped it. But I got this error when I try to login to TFS
TF401054: The requested service level property TFS_SERVICE_LEVEL did
not match the expected value. Team Foundation Server requires the
Dev16.M122.7 service level but the database currently implements
Dev14.M113.
I hope you have backups of your databases in a known good state; your best bet is going to be to bring back up a working TFS 2015 instance and then follow modern upgrade documentation.
The basic problem is that your team project collection databases have to be upgraded. Pointing TFS 2017 to TFS 2015 project collection databases without putting those databases through the normal process of attaching them (and thus upgrading them) isn't going to work. In a migration-based scenario, this is typically accomplished via the TFS admin console.
You may be able to go to the admin console and attach the databases, but my recommendation would be to bring up a working instance of your TFS 2015 environment and start from scratch.
We were working on TFS2015 and SQL2014. Our plan of this month is upgrading to TFS2017update1 and SQL2016.
I have created a test environment on personal VM. My process :
Back up TFS database in SQL, upgrade SQL2014 to SQL2016
Upgrade TFS2015 to TFS2017update1
Restore the database.
Everything works well except step #3. I was not able to restore the database back to TFS2017. Any suggestions?
The error info:
TF30046: The instance information does not match. Team Foundation
expected 368f7830-1c67-4c4c-8bc4-ba3d5b5a5543 which was not found.
Please contact your Team Foundation Server administrator.
First, suggest you to go through the event log on your machine to see if there are some useful info for troubleshooting.
If you're using SQL Server 2016, we require a Visual C++ runtime
update to be installed.
Double check your environment, make sure you have installed a Visual C++ runtime.
Besides, since you are going to update TFS 2017 Update 1, which the support SQL2016 version minimum is SP1.
TFS version Support SQL Server version
TFS 2017 Update 1 SQL Server 2016 (minimum SP1)
SQL Server 2014
More details please refer TFS Requirements and compatibility.
You could also follow Pero P.'s suggestion,select the Pre-Production upgrade, ignore the restore.
I am developing with BizTalk for the first time. I have created an extremely basic project in VS2103 which builds but fails to deploy with the output:
error DEPLOY: The database or the database version is incompatible with the installed version of this product.
The BizTalk installation is BizTalk 2013 R2 on a SQL Server 2012 SP3 database.
My project is using VS2013 because I understand that VS2105 can't be used to target BizTalk 2013.
There is no further information in the output window. I have a valid login on the database and can perform CRUD operations on it through VS2013.
This page suggests I need "SQL Server Development Tools" - am I right in assuming this means "SQL Server Data Tools" because that's all I seem to get when I search for it.
Even a pointer to where I can find a more more informative error would be useful (perhaps unsurprisingly changing the build verbosity only affects the build output when what I'd like is a more informative deploy output!).
Apparently this issue is related to the OS - BizTalk 2013 (or some other element of my setup) isn't compatible with Windows Server 2012 R2. Downgrading to R1 isn't an option the security team will allow. Upgrading BizTalk means upgrading SQL Server means upgrading some other software we have running on it so that's not going to happen any time soon. Looks like it's time for me to move to Azure!
Aha! -- this is probably it. On the very weekend I elected to set up the DNN site on Azure ... Web and Business versions are deprecated / retired. As of yesterday in fact, this is what is on Azure.
The ONLY 2 choices in SQL Server 2012 SSMS however, to import a data tier app are just Web and Business. Basic, Standard and Premium are not in the drop down in SSMS 2012.
So ... rather than just zap this question I'll put in another question within it. Is there an update to SSMS 2012? I ask because the database being migrated is 2012 so using SSMS 2014 may not work, if the option is to download this version of SSMS and use it.
Other than that ... here's what's already posted:
Note, the SQL Server database being migrated is 2012. DNN Version is 07.02.01 (367).
I'm following the steps in this blog link to migrate a DNN site to Azure: http://www.dnnsoftware.com/community-blog/cid/154975/moving-a-dnn-install-to-microsoft-azure-websites. The error I get is:
'web' is not a valid database version in this edition of SQL Server.
I have 2 choices in the import process 'Web' and 'Business', tried both and neither will work. There are a few other Stack Overflow questions on this but these are either not answered or the answers don't work.
I realize this is vague but it's simple enough: It doesn't work. :) The blog is followed to the letter. The .bacpac file is created with no errors. Importing the data tier step just results in the error that creating the target database on Azure failed for the above reason.
I have a support ticket in to Azure for this as well.
There has to be a simple, overlooked something -- a missing config step on setting up Azure. It could be the free trial doesn't cover this and I need to pay for something. That's fine ... just need to know what it is.
Who has run into this and actually, factually solved it?
My recommendation is always to use the latest SSMS version available, in order to have the latest updates supporting new Azure features like: full-text search support for Azure SQL Server v12, the long requested "Edit top 200 rows" working, the table designer, and a long etc.
Note that the latest SSMS release supports SQL Server 2016 through SQL Server 2005, so is going to work fine with your SQL Server 2012 database. On the SSMS June 2015 Preview, the following item was added:
Import/Export wizard support for new Azure SQL Database service tiers (Basic, Standard, Premium).
You can read more at https://msdn.microsoft.com/en-US/library/mt238290.aspx
https://support.microsoft.com/en-us/kb/3031047
For future reference. This hotfix should work on this problem.
That is because the valid database version could be basic or standard or premium. SSMS does not allow to choose it, therefore, the solution is to download the latest version of SSMS.