locked
Anyone tried the WI Auto Increment modification script in their Prod environment? RRS feed

  • Question

  • We're migrating from SCSM 2012 to 2016 (1801) with assistance from Cireson.  We've used the LMA tool to move stuff over, and on the whole, things look great.

    However, we ran into an interesting quandary with Work Items.  After doing an initial import, and then several delta imports, we noticed in testing that our WI #s were super high.  To wit, in our 2012 env, our IRs and SRs were in the high 200K, e.g. SR295101, IR295155, etc.

    But after the imports, in the new 2016 env, the first test SR we made was like SR919367!!  WAY too high for our current sequencing.

    So, we discussed with our consultant and referred to this old article from Travis Wright:

    https://blogs.technet.microsoft.com/servicemanager/2010/09/27/top-secret-trick-how-to-change-the-auto-incrementing-value-range/

    Shows how to change the starting value for the autoincrement.  Our plan then is to set it to a number near the range we're presently in.  All the 2016 work items have been removed using PS; and the relevant ServiceManagement and Cireson Analytics tables truncated.  We will redo the import of all WI's from scratch (I've tested several iterations) and it brings the final autoincrement number closer to about SR/IR350000 or so, which is much more acceptable.

    So the burning question is:  has anyone else tried this in a Prod context?  Or a Prod migration context?  Any success?  Any failure (massive or otherwise)?  Any inexplicable or unexpected behaviors as a result?

    Thanks for any insights!


    Friday, June 8, 2018 6:31 PM

Answers

  • I did something similar at one of our customers.

    You just have to make sure you enter a "FirstAvailableValue" that is not already in use in SCSM.

    Hope this helps.


    Andreas Baumgarten

    Saturday, June 9, 2018 10:53 PM

All replies

  • I did something similar at one of our customers.

    You just have to make sure you enter a "FirstAvailableValue" that is not already in use in SCSM.

    Hope this helps.


    Andreas Baumgarten

    Saturday, June 9, 2018 10:53 PM
  • Greetings!

    Because we were first doing an import (using the LMA tool from Cireson), the import itself was causing this table to increment.

    As such, in our new environment, we set the value to a *lower* value than our WI's.  EG, our oldest WI was IR299047 in our 2012 system, prior to import.  We set the value in the new 2016 system at ..225000.  When we then performed the import from 2012 to 2016, this table incremented based on the WIs being brought over.  Once the import was complete and we transitioned over to the new 2016 system, the first live/active WI then was IR432586.  A bit higher than I wanted, but at least not in the 900K like our first effort at it.

    All WIs have incremented normally since that time.

    Thanks for the input!

    Tuesday, July 3, 2018 4:13 PM