Hi all,
I’ve heard a lot of buzz about converting security from earlier versions (8 or 9) to version 10. Most of what I have heard is “don’t do it”. I disagree. Do it, but understand the ramifications.
Why Convert?
The first (and only) ramification I can speak to is that you can get up and running more quickly by converting your current security than by completely re-doing your security using the new v 10 concept. In my world, if my clients had to re-do their security they would possibly never convert. Converting security to the new paradigm for a site with many users and many companies is an onerous task; and that’s putting it in a good light.
Making it Easier
Before you upgrade, you need to ‘skinny up’ your security such that you end up with the minimum number of tasks after the conversion.
For example, if you have 8 users and 6 companies, and each user has the same security for each of the companies he/she has access to, then after conversion each user has a task and role and Alternate/Modified Report ID for each company. Wow! Don’t do that.
This recommendation came to me from Sheila Jefferson-Ross, an experienced (read over 15 years) consultant near Sacramento, California.
Before conversion, remove access from each company for each user who has the same security for each company. Whew, that’s another one where reading it again won’t help. Let’s look at an example.
Bob has access to three companies. His security is exactly the same for each company. If the conversion is done ‘as is’, then after conversion Bob will have a task for each of the three companies. Each of these tasks will roll into a role for each company. Multiply this for each user, and you end up with more identical tasks than anyone wants to manage.
In order to minimize the number of Tasks/Roles/Alternates, simply remove Bob’s access from two of the three companies before conversion. After conversion, grant him access to the other companies and copy the security from the first company to the other two.
You will end up with a manageable number of roles until the security is re-worked to embrace the v 10 model. Go ahead and convert! Version 10 has so many enhancements on v 9; don’t let the new security model slow you down!
Until next post!
Leslie
Hi Leslie,
ReplyDeleteNice suggestion about the security conversion... Problem is that most partner don't even really know the impact of using this tool to migrate toward GP 10.0, and most of the time it ends up in a big mess like you describe in your post. At my present company when I arrived, the deal was done since many months and the user suffered from incredible long login times (up to 5 min) and this process drained a lots of CPU res sources on the SQL server side. Until I figured out how the GP10 new role-based security model was built and created a couple of security reports outside of Great Plains to help me to find my way in this 'dedalum dynamicum' :-), since the GP reports are just useless for this purpose. After 3 months of work (not full time of course), all my users were assigned to the new role-based security and I could delete millions of records from the security tables (I had ~ 150 users across 5 companies, I let you imagine the mess).
Keep posting such interesting articles where we can share our experience (and experiments :-) ).
Have a great day,
Beat
Thanks for the comment Beat! Wow, a 'Daedalian Dynamicum', how cool; I had never thought of that. How fitting.
ReplyDeleteHopefully we can reduce the shock of the conversion role explosion. Boy, 150 users across 5 companies! No thank you :)
Leslie
Hi Leslie
ReplyDeleteThis is also discussed in my post
http://blogs.msdn.com/developingfordynamicsgp/archive/2008/11/24/information-about-using-v10-0-security-conversion-tool.aspx
which is part of the Application Security series.
http://blogs.msdn.com/b/developingfordynamicsgp/archive/2008/11/10/microsoft-dynamics-gp-application-level-security-series.aspx
David
http://blogs.msdn.com/DevelopingForDynamicsGP/
Thanks for the link David!
ReplyDelete