none
Failing upgrade to 4.4.1459.0 RRS feed

  • Question

  • Hi all.

    Tried upgrading my MIM2016 environment to the latest hotfix today. Sadly it broke completely. After an hour of digging I've found the core error:

    Cannot find the database 'FIMService', because it does not exist or you do not have permission.

    Well, it doesn't surprise me it doesn't find any database with that name. My database is named "MIMService" (this happens during batch 680). So obviously someone at Microsoft thought it would be a good idea to hard code the name "FIMService" in the upgrade scripts instead. Anyone know how to get past this? This resulted in my database being completely broken, but after a db restore I'm now up and running again on the "old" version (ie before the hotfix).

    Wednesday, April 12, 2017 2:10 PM

All replies

  • Hi,

    I remember that there was a similar issue in the past with a update or hotfix. So sad to have that again.

    That is one of the reasons why I dont change the Default Name for the DB, makes also no sense to me since I can't rename the SyncDB.

    I think you will only have 2 Options:

    1. Wait for a newer hotfix which will correct the issue (I'm quite sure if thats a bug, there will be one)

    2. Reinstall Portal/Service with re-use DB and rename the DB before to the default.

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Thursday, April 13, 2017 7:28 AM
  • If we look in the 4.3.2195.0 hotfix rollup this is listed as a fixed issue in FIM Service.

    https://support.microsoft.com/en-us/help/3134725/hotfix-rollup-package-build-4.3.2195.0-is-available-for-microsoft-identity-manager-2016

    It says...

    MIM Service

    Issue 1

    During the 4.3.2064.0 hotfix installation, the database upgrade fails if the FIM Service database name is not the default name of FIMService.

    The error now in 4.4.1459.0 is some kind of regression bug I guess. 

    Thursday, April 13, 2017 7:34 AM
  • Hi Daniel.

    I have successfully updated to version 4.4.1459.0 with a different database name.

    The version I upgraded from was 4.4.1302.0.  Is this the same version you are upgrading from?

    We upgraded from the latest version of FIM 2010 R2 to MIM (Using the MIM Upgrade Fix) to MIM SP1.

    If you go to the folder where the Service is installed, their should be a file called MicrosoftIdentityManagement.DatabaseUpgrade_tracelog.

    If you open that file, and look for the time stamp that matches when you tried to do the upgrade, it should show the connection String it used when trying to do the update.  Looking at the file on the machine I installed the update on, I can see that the Initial Catalog that was used is MIMService01.

    I have just spent a bit of time going through the logs, and just spotted this:

    "

    Microsoft.ResourceManagement Verbose: 0 : SQL Agent jobs were added

        DateTime=2017-04-12T21:28:41.0792942Z

    Microsoft.ResourceManagement Warning: 2 : The SQL Server Service Broker could not be enabled: System.Data.SqlClient.SqlException: User does not have permission to alter database 'FIMService', the database does not exist, or the database is not in a state that allows access checks.

    ALTER DATABASE statement failed.

    User does not have permission to alter database 'FIMService', the database does not exist, or the database is not in a state that allows access checks.

    ALTER DATABASE statement failed.

    User does not have permission to alter database 'FIMService', the database does not exist, or the database is not in a state that allows access checks.

    ALTER DATABASE statement failed.

    User does not have permission to alter database 'FIMService', the database does not exist, or the database is not in a state that allows access checks.

    ALTER DATABASE statement failed.

    Cannot find the database 'FIMService', because it does not exist or you do not have permission.

       at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)

       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)

       at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)

       at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)

       at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)

       at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)

       at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)

       at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()

       at Microsoft.IdentityManagement.DatabaseUpgrade.Program.EnableServiceBroker(SqlConnection connection)

        DateTime=2017-04-12T21:28:41.1261596Z

    Microsoft.ResourceManagement Verbose: 0 : Database upgrade : Database schema upgrade completed successfully."

    The last line does show the Database been upgraded successfully, and from what I can tell, in my Dev and Test environment, everything is working as expected.  However, it might be worth someone from Microsoft having a quick look to see if they can fix this at some point.

    I wonder if it is the error message that is wrong, it might be worth checking that the account you are installing the hotfix has SA permissions on the database, and see if that fixes the problem.

    Hope that helps,

    Ian

    Thursday, April 13, 2017 8:18 AM
  • Ok... I tried simply removing my database to FIMService (because I have no real reasong for another name, just thought when I installed that MIMService sounded better) but the installation still fails so I guess the database name may have been a red herring.

    Now I'm struggling with the same error as the guy in this thread, seems it has something with my bindings to do. I haven't done anything out of the ordinary though so I can't see what would case this :-(

    Thursday, April 13, 2017 8:42 AM
  • After the failed install did you look at the version number the db has?  If fim.version table in the service db got changed to something like -1 it will fail until you change that back to proper numbers.  I run into this all the time in my lab adding hotfixes and troubleshooting failed instal issues.   One of the big ones is if you have a box that is not current to the other ones in the loadbalance and you need to add a few hotfixes you have to manually change this number to get it to work or it will error out every time .
    Friday, April 14, 2017 6:04 PM
  • Yep, you're correct, it was -1. My interpretation of this was that it set the version to -1 at the start of the installation and then it sets it to the correct value when the installation is finished, which would lead to it still being -1 if the installation never finishes because of a failure. Manually changing it when it's in this state seems kinda dangerous since I have no clue what stuff of the installation has been done and more important what it didn't do. Or am I thinking completely wrong here?

    What I did about the -1 was simply restoring a backup of my database from before trying any upgrade, this way at least it works with the "old" version. Problem now is that the upgrade did succeed on my sync service which now refuses talking to mim service because of version mismatch...

    Friday, April 14, 2017 8:19 PM
  • Hi.

    I'd just like to report back on this. I contacted Microsoft Support and got the answer that I'd encountered a problem that seems highly unusual and that the product team would require 2-3 months for even looking at it. So I ended up doing a total reinstall of my service and portal (with export/import of complete policy and schema). So a couple of days later I'm back on track with updated version. I just hope this won't happen next time there's a hotfix, this way of doing it is not an option once the system is in production...

    Tuesday, May 2, 2017 6:49 AM