You can run it during the night.
The problem is that you need to record the movements (opening Navision, logging in, running the synchronize) with some keyboard-recorder. And then you can run it on some computer (of course physically protected in a room behind a locked door).
Another possibility is to make everyone DB-owner. With this synchronizing is not necessary anymore. BUT: In this case, you must be sure no one is able to access the DB with external tools, because they can do anything in the DB.
So this can be dangerous!
I have used a program called Auto IT before to do some keyboard movements capturing etc. It was ok. But I wonder if this is the most effecient method.
My best win would be a SQL stored procedure of some sort. [H]. I downloaded a sample posted on another forum by “ChoiceSolutions” and it looked promissing but did not seem to actually work (i.e. Perform Navision Synchronise - but it was much quicker at doing whatever it did)
I don’t think I will be making anyone DB owner, although I like the idea of making synchronising not necessary anymore [:D].
We use it at one client and it works great. It does not work for AD groups though; the Navision roles have to be assigned to each window user. It does not work for database users either.
It takes 10 seconds though to synchronize one user (as long as that user is logged off) instead of the 5 minutes it takes with the Navision way (and it locks everyone out while it is in process too).
I manually run it at night when necessary through Remote Desktop from home. It averages about 45 seconds or so per each user, so it will easily take me about 45 minutes to do the entire process. Wonderfully, you also do not get any sort of status of what it is doing, just a blank screen when using it over Remote Desktop. Anytime that I have tried to synchronize a single user while people were on the system, I would get a lock.
It is not suggested to make everyone db_owner, but this is useful for those situations when you need to quickly get a user working. This should only be used as a stopgap solution.
Hey, it worked, kinda [:|]. It worked the first night. But then some database logins were removed directly from SQL instead of deleting them in Navision Database logins (Yes I am using both database and windows). Anyway it appears Navision does not like this and complains saying that the Database Login does not exist on SQL. So this in turn affects my script which stops the Synchronise all… but otherwise it works.
A new exe-file (dated 14-august ver. 18.104.22.16899) with a white paper about “Synchronizing security in Navision 4.0 SP2” has been issued. This gives a new option to use standard security (seems very close to 3.6 security) and enhanced security (existing 4.0 security).
So I think this might solve out problems to choose standard security. I have not yet tested it but will do so asap.
It is still so new that it is not available as rollup but only a hotfix (KB922695) - but as a white paper now exist stating sucurity in 4.0 SP2 I assume it will be a rollup soon.
SP3 will contain the option to continue either with Enhanced security, as introduced in 4.0, or Standard security as in previous versions. The choice can be made anytime as a Database Alter dialog option. The database upgrade will continue with whichever model is used in the version being upgraded (e.g. upgrading 4.0 SP2 will continue with Enhanced; upgrading 3.70 will continue with Standard) until it is explicitly changed with a Database Alter.
The Standard security option (i.e. previous model) only sychronizes Navision users/logins against SQL Server logins, as has always been the case in versions prior to 4.0.
So far my tests are promissing. Before the conversion I set db to single user mode. Change the exe’s then convert. Am able to go back into database → alter without error.
Changed my security model to standard, deleted all the Windows logins except AD group logins, ran synchronise and hoorah it works the old way. So now only have around 10 AD groups to synchronise insteard of 400+ users - HUGE time saving. I am quite happy with the security of just using the standard model - I think its all up to how Active Directory users are managed.
I hope there are no further bugs with this hotfix. (I will post if I find any).