Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
I'm trying to upgrade a 2015 on-prem installation to 2016. I'm using the same admin account to install as when I installed originally, same service accounts specified, etc...
When I get to the "System Checks" page, it checks off Operating System and Server User Input, and then moves onto CRM Database, where it just sits and does not progress. When I look in the logs, I can see it going through the Database check section, and the final lines are:
---------------------13:24:09|Warning| Check SqlDefaultValueConstraintValidator : Warning: The default value constraints in the Microsoft Dynamics CRM database are not consistent with Microsoft Dynamics CRM default value constraints.13:24:09|Verbose| Connecting to database Data Source=DBSVR01\DYNMSCRM;Initial Catalog=CAWST_MSCRM;Integrated Security=SSPI.
And this is where it's just sitting. Server isn't crashed, no non-responding processes....just, nothing's happening. (Note: there are a few other db checks that happen before this, and it gets past those just fine.)
So I tried just upgrading the server without upgrading the org, and that worked fine. Then in the Deployment Manager I try just upgrading the org, and it hangs again. The crmdmsnapin log shows the exact same final lines as above before it just stops proceeding.
This org was created in CRM 2015, so not some old version that's been updated over and over, or anything like that. And we haven't touched the DB directly or done anything out of the ordinary with the organization or its config.
Any ideas as to what I can try next, or where else to look? Out of curiosity, has anyone done this successfully yet?
Thanks for your reply. I have added the 2 reg keys, and about to try the upgrade again. I will keep you posted about my findings.
I did all the database cleaning and registry settings - the CRM setup routine is working now for more than 10 hours on the "Microsoft Dynamics CRM Database" step causing CPU load on the SQL server at all time.
I will let it run over night, but don't think that this will lead somewhere.
My database is rather small and I rather tend to expect just the timeouts prolonged due to the registry tweaks, but not the actual issue in the instance addressed.
Has anyone tried using SQL Profiler to trace where the upgrade organization is hanging? This sounds like an MS build problem.
No change after letting it run over nigth. It just hangs during System Check when checking the database. Last entry in log file is:22:46:30|Verbose| Connecting to database Data Source=SQL;Initial Catalog=CRM_MSCRM;Integrated Security=SSPI.
Just to be clear, the actual upgrade never starts because the System Checks never finishes.
CRM database is only 1 GB
The first impression of upgrading MS CRM 2015 to CRM 2016
Firstly, uninstall MS CRM 2015 reporting extension from server.
For this warning; Existing SQL Server connections to the Microsoft Dynamics CRM databases must be closed before setup can continue. The following connections need to be closed before setup can continue
Stop Microsoft Dynamics CRM Asynchronous Processing Service and Microsoft Dynamics CRM Asynchronous Processing Service (maintenance)
For this error;We have detected the presence of legacy component(s) during upgrade, these components are not supported in Dynamics CRM 2016. Please refer to upgrade log file C:\Users\administrator\AppData\Roaming\Microsoft\MSCRM\Logs\LegacyFeatureCheck.xml for more information
Checking for the ISV folder when running on the web server
Also for me, I was not able to proceed applying the database clean-ups and registry tweaks. The setup routine ran overnight and timed out, again.
I tried to further trace the issue by the comments above. Although not very familiar with MS SQL tracing, there seem to be an endless loop:
Also, the LegacyFeatureCheck.xml contains only zeroed component-ids and issues xml elements with zeros.
Having the same problem, I discovered the following TSQL using the SQL Activity Monitor:
while (@@FETCH_STATUS <> -1)
if (@TableName = 'DocumentIndex')
set @columnCount = @columnCount + 1
if( @FullTextColumnName COLLATE Latin1_General_CI_AI not in ('Title', 'KeyWords', 'SearchText'))
set @modifiedFTIndex = 1
fetch next from @mycursor into @TableOwner, @TableId, @TableName, @FullTextColumnName, @FullTextColID, @FullTextBlobColumnName, @FullTextBlobColumnId, @FullTextLanguage
if (@TableName = 'BusinessDataLocalizedLabelBase')
set @businesDataLocalizedLabelColumnCount = @businesDataLocalizedLabelColumnCount + 1
if( @FullTextColumnName COLLATE Latin1_General_CI_AI not in ('Label'))
set @modifiedBusinessDataTableFTIndex = 1
To get the TSQL statement, I used the following query, where 65 is the session I found using the activity monitor
FROM sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext where req.session_id = 65
For me the statement would never complete, because my CRMFulltextCatalog also contains other columns. It looks like the problem is the “fetch next from @mycursor …” which won’t be called for columns other than 'DocumentIndex' or 'BusinessDataLocalizedLabelBase'. So this is where the endless loop is coming from.
Therefore I removed all other columns from my CRMFulltextCatalog except 'DocumentIndex' and 'BusinessDataLocalizedLabelBase'.
Finally the system checks went through and I was able to perform the upgrade!
I can confirm that the upgrade can be performed after removing all tables from the full text catalog "CRMFullText".
Unfortunately, after the upgrade, searching all entities results in a Generic SQL Error message. Furthermore, the general CRM search does not return any results, as well.
The event log has the entries error 24065 MSCRMPlatform and warning 1309 ASP.NET
StackTrace: [CrmException: Generic SQL error.] bei Microsoft.Crm.Application.Platform.ServiceCommands.PlatformCommand.XrmExecuteInternal()...
Microsoft.Crm.Core.Application.WebServices.AppGridWebServiceHandler.ProcessRequestInternal(HttpContext context)[XmlException: Microsoft.Crm.CrmException: Generic SQL error. bei Microsoft.Crm.Application.Platform.ServiceCommands.PlatformCommand.XrmExecuteInternal() bei Microsoft.Crm.Application.Platform.ServiceCommands.RetrieveMultipleCommand.Execute() bei Microsoft.Crm.ApplicationQuery.HierarchyAwareRetrieveMultipleCommand.RetrieveData() bei Microsoft.Crm.ApplicationQuery.ExecuteQuery() bei Microsoft.Crm.Application.Platform.Grid.GridDataProviderQueryBuilder.GetData(QueryBuilder queryBuilder)... Microsoft.Crm.Core.Application.WebServices.AppGridWebServiceHandler.ProcessRequestInternal(HttpContext context) bei System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() bei System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I think this issue might be a consequence of modifying the CRMFullText catalog.
Thank you everyone in this thread for pointing me in the right direction. Not sure if this will help anyone else, but I wrote a little script to regenerate the CRMFullTextCatalog. I ran this script before upgrading, then manually removed all tables/views from the Catalog. After the upgrade was complete, I ran the output generated by this script, which re-populates all the tables/view back into the CRMFullTextCatalog, putting it into the pre-upgrade state (keep in mind that the index must rebuild after running the script). I make no guarantees this will work in your environment, but it appears to have worked properly for our test migration.
declare @catid int
select @catid=fulltext_catalog_id from sys.fulltext_catalogs where name='CRMFullTextCatalog'
declare c cursor for
select sys.tables.name, sys.fulltext_indexes.unique_index_id from sys.fulltext_indexes inner join sys.tables on sys.fulltext_indexes.object_id = sys.tables.object_id where sys.fulltext_indexes.fulltext_catalog_id=@catid
declare @TableName varchar(200), @UniqueID as integer
fetch next from c into @TableName, @UniqueID
while @@fetch_status = 0
declare d cursor for
select sys.indexes.name, sys.tables.object_id from sys.tables inner join sys.indexes on sys.tables.object_id = sys.indexes.object_id where sys.tables.name=@TableName and sys.indexes.index_id = @UniqueID
declare @KeyIndex varchar(200), @object_id as integer
fetch next from d into @KeyIndex, @object_id
if @@FETCH_STATUS <> 0
Print 'Error with' + @TableName
Print 'CREATE FULLTEXT INDEX ON [dbo].'+@TableName+' KEY INDEX ['+@KeyIndex+'] on([CRMFullTextCatalog]) WITH (CHANGE_TRACKING AUTO)'
declare e cursor for
select sys.columns.name from sys.columns inner join sys.fulltext_index_columns on sys.columns.object_id=sys.fulltext_index_columns.object_id and sys.columns.column_id=sys.fulltext_index_columns.column_id where sys.columns.object_id=@object_id
declare @ColumnName varchar(200)
fetch next from e into @ColumnName
Print 'ALTER FULLTEXT INDEX ON [dbo].'+@TableName+' Add ('+@ColumnName+')'
print 'Error' + @KeyIndex
Thanks for all the effort.
I basically got everything working now. I removed all columns prior to upgrade, upgraded. Then, the full text search was broken. I just disabled it, rebooted, and enabled it again in the general system settings.
It also took some time (hours), reboots, and second trigger of a aborted full text indexing job, but all is working now.
Working for me now as well, and answers appropriately marked. What a mess, eh? Great work tracking it down!
Thank you for the effort as well. We got stuck in system chceck phase of installation, where checks of Microsoft dynamics CRM database took hours (after we modified timeouts in registry).
However, after removing tables from Fulltext catalogue, upgrade was no problem.
I am having the exact same issue. I have tried all the recommendations and it basically runs forever and never completes. I installed 2016 on a new crm server (and a new SQL server) with a default organization just fine. When I try to import our current 2015 organization it never completes. No errors, it just runs forever....
I can confirm that following the instructions and running Edward Ainsworth's script detailed above works and allows the upgrade process to proceed through to a successful conclusion.
It was bad enough that on-premise customers were denied access to CRM 2015 Update 1 for over half a year. That Dynamics 2016 could be released without first testing the blatantly flawed upgrade process beggars belief, even for the bone-idle, in-bred morons on the Microsoft Dynamics CRM team.
Thanks for posting this. I am not so familiar with exactly how to manually removed all tables/views from the Catalog
I wonder if you would mind dumbing this down a few shades for us please.
Thanks for getting back to us Edward. We understand your apprehension here. Would you mind looking over this blog post we have created to help others, and commenting if this is achieving what you intended.
Thanks in advance.
Thank you for posting this thread. It helped me solve this timeout issue and upgrading on-prem 2015 to 2016
CRM 2016 Update 1 was released this week and fixed the import organization system check timeout issue for our 2015 to 2016 upgrade (along with quite a few other things, see KB 3133963 link below).
Issues Resolved: support.microsoft.com/.../3133963
Upgrade 2016 first apply 0.1 update, import ORG