Ya, set a GCV with the latest high water mark

Then change the starting point of that loop to use the GCV value. So now you can control where it starts.  So start it at 174,000 and go from there.  Then in a year, increment the GCV to some higher number that matches the current high water mark.

Second approach:  Use Last Referenced Time attribute on the Driver object to store the high water mark.  So as you enter that loop, read the Last Referenced Time value, get the last High water mark value, use that as the start of your loop. 

When done, write back the value you just used to Last Referenced Time. (One complexity is that the syntax is Invterval I think, which has a DN and two integers?  Use one of the integer values to store what you need.

There are ups and downs to both approaches.

I just re-read that, and you do not have a loop doing teh work, you are using the Unique Name token, to generate an integer value.  You could chop off the last 2 digits of high water mark, append two zeros, and use that as the pattern.  I.e. CN17400 and then let it look for the next available number.

Thanks for the response. I like the GCV idea with the use of counter-start=driver.usercreation.CNCounterStartValue

. I presume I would need to modify our code via designer then recompile/push the code? I'm not super knowledgeable about that component... I'm just the last employee left.

Thinking about my response...  The problem is that in Unique Name, there are no variables supported in two important fields.  (Tested it, not supported).

The Start and # of digits.

So I tried as shown above, taking the GCV value (as you named the GCV) and subsring off the last 2 digits, and then stick back on 00 so it will always check a bunch, but not 174,000!!!

But that sticks on 10 digits at the end.

<do-set-local-variable name="var-newnumber" scope="policy">
	<arg-string>
		<token-unique-name counter-digits="10" counter-pattern="all" counter-start="1" counter-use="always" name="CN" on-unavailable="error" test-all-objects="true">
			<arg-string>
				<token-substring length="-3">
					<token-local-variable name="start"/>
				</token-substring>
				<token-text xml:space="preserve">00</token-text>
			</arg-string>
		</token-unique-name>
	</arg-string>
</do-set-local-variable>

So then I thought, you could say the Digits field instead of 10 should just be 2.  But if you roll over to 1 million numbers you need to update that.

I think the Last Referenced Time approach is the best. 

But it is more complex.  Not hard, just more complex.

And I figured I would give it a quick try...  This is probably pretty close to what you need.

	<rule>
		<description>[CIS] Make sure high water mark for users is in memory</description>
		<comment xml:space="preserve">Load High Water mark into memory.  Got the idea from Lothar Haegers' Pasword Notifier Driver.</comment>
		<comment name="author" xml:space="preserve">Geoffrey Carman</comment>
		<comment name="version" xml:space="preserve">1</comment>
		<comment name="lastchanged" xml:space="preserve">Aug 3, 2023</comment>
		<conditions>
			<and>
				<if-local-variable mode="regex" name="HIGH-WATER" op="not-equal">.+</if-local-variable>
			</and>
		</conditions>
		<actions>
			<do-set-local-variable name="HIGH-WATER" scope="policy">
				<arg-node-set>
					<token-src-attr name="Last Referenced Time">
						<arg-dn>
							<token-global-variable name="dirxml.auto.driverdn"/>
						</arg-dn>
					</token-src-attr>
				</arg-node-set>
			</do-set-local-variable>
			<do-set-local-variable name="HIGH-WATER" scope="driver">
				<arg-string>
					<token-xpath expression='$HIGH-WATER/attr[@attr-name="Last Referenced Time"/value/component[@name="seconds"]'/>
				</arg-string>
			</do-set-local-variable>
		</actions>
	</rule>
	<rule>
		<description>[CIS] Your create rule here</description>
		<comment xml:space="preserve">Merge this into your create rule, whatever your conditiins.</comment>
		<comment name="author" xml:space="preserve">Geoffrey Carman</comment>
		<comment name="version" xml:space="preserve">1</comment>
		<comment name="lastchanged" xml:space="preserve">Aug 3, 2023</comment>
		<conditions>
			<and/>
		</conditions>
		<actions>
			<do-set-local-variable name="var-newnumber" scope="policy">
				<arg-string>
					<token-xpath expression="number($HIGH-WATER) + 1"/>
				</arg-string>
			</do-set-local-variable>
			<do-trace-message>
				<arg-string>
					<token-text xml:space="preserve">Do your work here with the variable.  Then update the HIGH WATER mark in the next action when it is appropriate.</token-text>
				</arg-string>
			</do-trace-message>
			<do-set-src-attr-value name="Last Referenced Time">
				<arg-dn>
					<token-global-variable name="dirxml.auto.driverdn"/>
				</arg-dn>
				<arg-value type="structured">
					<arg-component name="seconds">
						<token-local-variable name="var-newnumber"/>
					</arg-component>
					<arg-component name="replicaNumber">
						<token-text xml:space="preserve">0</token-text>
					</arg-component>
					<arg-component name="eventId">
						<token-text xml:space="preserve">0</token-text>
					</arg-component>
				</arg-value>
			</do-set-src-attr-value>
		</actions>
	</rule>

And as an aside, this is what I do in my day job if you guys are looking for more help...

The quick and easiest thing for him would probably be to just manually correct starting value, from 0 to 174,000 directly in the unique name action (perhaps it can be done through iManager? I have never tried).

Would not write it but I had one idea: how about you just use the attribute with the driver stats? Which tells you how many add operations were processed.

Of course, there are a lot of downsides to losing this when:

• losing the actual stats
• moving the driver
• going live in existing system, so a lot of users would match and would not count as an "add" operation I think

So my solution is not useful, but perhaps will be handy for someone else in the future.

I thought about that first idea.  Sinmply change the start value from 1 to 174000 and in a year, go do it again to the current high water mark. That does not entirely solve anything but masks the problem for a period of time.

As for the driver stats, that is DirXML-DriverStorage, which the driver overwrites every startup so not as helpful.

Create an Aux Class which is added to the driver object - which contains an attribute which I then update every time I have created a new ID.

That is simpler than Lothar;s approach, but Last Referenced Time is there and available to use if you want.

I do not like, for good reasons, like to add to the base schema, which is why I suggest using an Aux Class, and the structured attribute is what I also would do.

Thank you for the idea. Temporary path for quick resolution was to update the counter to start at 174,000. This minor change sped up the account creations to get through our backlog. Thanks for all the ideas everyone! I will definitely work on a proper long term solution.

Just out of curiosity... What tool did you use to update the value?