Open Forum

Upgrading from V2015 FP1 to V2018 CU1

  • 1.  Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 01, 2019 01:42 PM
    I am in ​the process of setting up a new Dynamics SL V2018 CU1 installation on a new platform in order to PILOT both this new version of SL and also to test the Azure platform.   I'd be interested in hearing from anyone who is either running or testing V2018 or V2018 CU1 in order to share your experiences and questions.

    In this thread, I thought I would document some of the issues I've find and (hopefully) overcome as I work through establishing our new pilot environment.   BTW:   When we're all done, we will be keeping the SQL Server install from the pilot, but expect to start over on the install of the Terminal Server/Citrix Server for go-live.

    Here's what I've done so far:
    1)   We have set up two machines on the Azure platform  - one a SQL server and one a terminal server.    The SQL Server is running Windows Server 2019 (I know, not supported but hopefully it will be before go-live in May/June) and SQL Server 2017.   The terminal server is on Windows Server 2016 Data Center Edition.   We currently run Citrix, but are piloting on Terminal Services only to see if their capability is catching up with Citrix.  Later on, we will reconfigure the Terminal Server to run Citrix, assuming we opt to continue using that platform.   Since Citrix is not as well supported, we wanted to surface issues on the Microsoft only platform initially.
    2)  On the SQL Server, we run Windows Authentication for all databases, but have a hybrid security environment.    I've installed our demo V2018 databases, and scripted the copy/restore of our LIVE databases (68+!!) to the new SQL Server.    The backup current version/copy to new server process takes over 4 hours.    The restore of 68+ databases takes another 2 hours or so as it upgrades to 120 compatibility level on SQL Server 2017.   Next I run "Synchronization"  on the V2018 databases because that will create corrected SQL logins for any users added in the current LIVE version that aren't on the new SQL server.   The Synch takes about 3 hours against the 68+ databases.    Finally I run the conversion against the databases, which is currently taking around 8 hours.
    3)  We configured the Terminal Services to publish Dynamics SL for pilot users to access SL.   We created a separate access rights group on Active Directory to only allow a few selected users into the pilot.    In our prior environment, we did not do a full install on the Terminal Server; this time we will.   So I've installed SL locally using the Control Panel option for "Install Application on Remote Desktop".    Note when I'm doing installs, my IT team lets me be a "domain admin for a day".
    4)  After much discussion on which version of Office we should install on Terminal Services, we opted to do a "Shared Install" of Office 365 Pro Plus.   The Office install is necessary in order to enable opening Excel from a grid on a screen (think Journal Entries) or to use Quick Query.     We have an Enterprise Agreement subscription license for Office 365, so we're leveraging that.     One "gotcha" is that Office was supposed to be installed before installing SL.   So it looks like I may have to reinstall SL now that Office has been settled on and installed.   However, I did specify that we didn't want a full install of Office - just Word and Excel.   We don't use email from within SL.
    5)  One sticking point that popped up in our deployment of the Terminal Server published app was the SSL certificate.    Since we are launching from a new location, the old SSL certificate currently installed on LIVE doesn't work.    We're going to have to acquire a new SSL certificate for purposes of the pilot and the time period while we have two concurrent instances of SL deployed - one for LIVE and one for the pilot's web location.
    6) We always forget to install a version of Adobe Reader which seems to always be necessary.    We do that using the "Install Application on Remote Desktop" as well.

    I have been surprised at the ease of using the Azure platform for the new serves.   It finally dawned on me that Azure (in this context) was replacing VM Ware for virtualizing servers.    The only thing we really see is that copying large files "up" to the servers can take a bit longer than inside of our domain.   I tested doing a restore and synch on the SL V2015 databases on the Azure server so that I could run those databases against our current Citrix/SL platform.    It did run, but I did seem to get a bit more problem with latency as the system tried to find the SQL Server.

    I've already had to work through a number of issues and open a few incidents as I've worked through getting the databases to upgrade.    Here are some of the things I've run into in moving my databases to a new server.    Some of the "gotcha's" in moving my databases to a new server included:

    -  I scripted the restore of the system database as a separate script from the restore of the application databases.    This script automatically updates the Domain.Servername to the new server name.    It also updates the screen color of each company in the company table to be "yellow" ( 65535) so that when I'm looking at the pilot screen, I can see I'm not in the production database.

    - Note that customizations CANNOT be upgraded.    When I restore my system database, I have to delete the contents of CustomVBA as customizations have to be re-
    imported after conversion.    This was an opportunity to review the existing customizations in live and remove the "self" customizations that had crept in.  I automatically delete contents of CustomVBA when restoring the System database from live.

    -  While I knew to change the System's domain table to point to a new server, I forgot that the database ownership for each one had to be changed to "sa".   Otherwise it -  was carrying my user name as the owner of the database.   We had a couple of other settings on the database that had to be fixed as well.

    - One lesson from running the conversion I learned while working with Terry Crayton at Microsoft.   Apparently, some sites have an issue with timeouts when trying to run the conversion.    He had me edit the DBBuild.INI in the DB folder to add these lines:
    [Settings]
    ConnectTimeout=3600
    StatementTimeout=3600

     - Another lesson is that the upgrade checks whether the UserRec.WindowsUserAcct field is active when it tries to create the logins for my orphaned users.   That is, my new SQL Server instances doesn't have the 100+ users I had on the LIVE SQL Server, and because I'd been a little lax in maintaining the SQL logins for terminated employees, I didn't want to automatically create all users on the new server that were on the old server.    When I restored my databases from live, they carried those old SQL accounts of inactive users in every one of my databases.    So I bit the bullet and ran my handy dandy SQL script that drops logins and clears out orphaned users (kindly provided by Kira Rodemacher - oh we miss her!).    This took care of the problem where I had an inactive user in UserRec with a blank value in the UserRec.WindowsUserAcct field but still had a SQL account in LIVE.    Then I ran the entire conversion process again (backup LIVE/copy to new server/synch/convert) to find that I still had a couple of users whose active directory account was inactive, only I didn't know it and still had their user ID's in the UserRec table.    So I corrected those, and finally had a clean run on the conversion - at least with regards to security.    At the end of the process I now how an up to date SQL login for all of my SL users on the new SQL server.   Yay!

    Current issues I'm working on include:
     - a couple of custom  SQL view the system is complaining about.
    - I'm having an issue with the menu group EVERYONE working differently between the two versions.
    - I'm starting to work on our add-ons so that will be interesting.
    - I'm already told there is no new Spanish Menu overlay although they are planning for it.    Stay tuned.

    If any one has any questions or comments, I'd love to hear from you.

    Best regards,

    Gail J-N

    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------


  • 2.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 04, 2019 05:40 AM
    ​One of my friends suggested offline that I might want to clarify our use of only two servers in our configuration for this pilot process.    To be clear, we are conducting a pilot - which means there will only be a very few folks on very lightly used servers.   On the terminal server, we are testing and documenting installation of SL and various third party extensions, our custom executables, documenting steps in the configuration process, what new Operating Systems look like, how robust is RDS by itself, what SQL Server 2017 looks like, etc.

    Before our go live for our 100+ users, we will start over in the configuration of our RDS (terminal services) or (likely) Citrix with several servers, providing as much redundancy as is cost effective.    Exactly how many servers we will be using is still being tuned and will be informed by findings in the pilot.

    Our SQL Server should be fine for go-live, although during the staging phase - that's the time when we've done our final configuration and are testing with all users - we may tweak the configuration in-place.   Since it's Azure, if we find we need more memory, server space, etc.  that can be added later.

    All questions and comments are appreciated!

    Best regards,
    Gail J-N

    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------



  • 3.  RE: Upgrading from V2015 FP1 to V2018 CU1

    BRONZE CONTRIBUTOR
    Posted Feb 04, 2019 09:03 AM
    Gail,
    I would be interested to know the upfront and monthly costs of maintaining your Azure environment.  That seems to be the big wild card with Azure.

    ------------------------------
    Kurt Bradley
    Bradley Consulting Group, Inc.
    Spring TX
    ------------------------------



  • 4.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 07, 2019 01:34 PM
    ​Good question, Kurt.

    I largely don't know what I'm talking about in the next paragraphs.    This is what I think I understand from my IT guy.   Other sources would probably be more reliable.

    It has been problematic to get a pricing answer out of my IT team, mainly because they're afraid I'll hold them to the costs they quote.   The way Azure is priced is like a very complicated menu - there's a separate charge for everything.   They charge separately for every drive in incrementally larger sizes - 128 Gig, 256 Gig, 512 Gig, 1 TB, etc..
    They charge separately for hourly usage,  data sent out to the internet, data sent over VPN, data used for backups, and many more.

    So all that said, and knowing we don't have a track record yet to determine the running cost, the best I could get was the bare minimum for our two servers.   The SQL Server has 4 drives (128/1 TB/256/512 ) and 64 Gig RAM  while the Terminal Server as 1 128 Gig drive with 16 Gig of RAM.

    Bare minimum pricing for us is somewhere around $1050/month, but as they say - prices may vary and they will - and they will be higher.  Until we go live, we won't know how much this is going to cost.

    To those on the forum who want to quote me a better deal - please don't bother.     I don't have anything to do with that decision.    Any threads that respond with a better deal will be removed.

    Hope this helps.

    Best regards,
    Gail J-N


    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------



  • 5.  RE: Upgrading from V2015 FP1 to V2018 CU1

    BRONZE CONTRIBUTOR
    Posted Feb 07, 2019 04:52 PM
    Thanks for the response.  The real question is the monthly cost after you have been operational for about six months.  The big problem that I see with Azure and AWS is that you have no idea what it will cost you, until it is too late.  I would be interested to know what the cost is for other Azure users.  And no, I have absolutely no interest in offering BCG Cloud Services.

    ------------------------------
    Kurt Bradley
    Bradley Consulting Group, Inc.
    Spring TX
    ------------------------------



  • 6.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 08, 2019 07:43 AM
    I agree.   ​I must say I find it somewhat amazing that our corporate policy is to move all servers to Azure when we don't actually know how much it will end up costing.    It's so interesting to see  IT services come full circle.   When I first started in the business back in the seventies, many larger users connected over phone lines to service bureaus who provided the software and hardware, and rented time on their big IBM computers.    The problem back then is that once you were entrenched on the systems provided by the service bureau, you had very little choice when the service bureau decided to increase prices.    They did, and thus was born the personal computer revolution in the 80's.

    Best regards,
    Gail J-N

    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------



  • 7.  RE: Upgrading from V2015 FP1 to V2018 CU1

    Posted Feb 04, 2019 11:16 AM
    Gail,

    Thanks so much for your post.  Did Terry mention changing your Query Timeout in SQL Server?  I experienced the timeout issues, too.  Changing the Query Timeout seems to have only resolved some of them, so I will try the changes to dbbuild, too.

    Mike

    ------------------------------
    Mike Lee
    President
    IT Evolution Management, LLC
    Milliken CO
    ------------------------------



  • 8.  RE: Upgrading from V2015 FP1 to V2018 CU1

    Posted Feb 05, 2019 09:24 AM
    ​Please keep me posted on the performance issues with Azure.  Getting ready to upgrade, but still hesitant about using a cloud platform for SQL.

    ------------------------------
    Betty Browning
    CIO
    Cleveland Group, Inc.
    Atlanta GA
    ------------------------------



  • 9.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 07, 2019 01:15 PM
    ​For our pilot, we are not attempting to optimize performance.     We'll do performance testing later when we actually configure our deployment architecture.

    Our pilot only contains two servers - SQL  and "everything else", so we're not expecting great performance.   Our final deployment will include redundant terminal servers, redundant Citrix storefront/licensing servers, and one SQL Server.    To improve performance, we will be installing our very complicated Dynamics SL application directly on both terminal servers, and will increase the RAM on both terminal servers and the SQL servers.   All servers will be on the Azure platform.

    I do notice copy speeds between our current in-house servers and the Azure cloud at ~25-28 MB/second.    However, once the files are on the Azure servers, I am seeing only slightly improved copy speeds between the two servers.   I keep a 25 Gig "junk" file on all of my SQL drives which I can delete in case something bizarre happens and a data or log drive fills up.    I copied that junk file between my two pilot servers and observed speeds at ~30-33 MB/second.    Copying between drives on the same server was significantly faster with speeds varying from  30 MG/sec -  1 GIG/sec, mostly in the 50-60 MB/sec range.

    Hope this helps!

    Best regards,
    Gail J-N

    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------



  • 10.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 07, 2019 01:17 PM
    ​For our pilot, we are not attempting to optimize performance.     We'll do performance testing later when we actually configure our deployment architecture.

    Our pilot only contains two servers - SQL  and "everything else", so we're not expecting great performance.   Our final deployment will include redundant terminal servers, redundant Citrix storefront/licensing servers, and one SQL Server.    To improve performance, we will be installing our very complicated Dynamics SL application directly on both terminal servers, and will increase the RAM on both terminal servers and the SQL servers.   All servers will be on the Azure platform.

    I do notice copy speeds between our current in-house servers and the Azure cloud at ~25-28 MB/second.    However, once the files are on the Azure servers, I am seeing only slightly improved copy speeds between the two servers.   I keep a 25 Gig "junk" file on all of my SQL drives which I can delete in case something bizarre happens and a data or log drive fills up.    I copied that junk file between my two pilot servers and observed speeds at ~30-33 MB/second.    Copying between drives on the same server was significantly faster with speeds varying from  30 MG/sec -  1 GIG/sec, mostly in the 50-60 MB/sec range.

    Hope this helps!

    Best regards,
    Gail J-N

    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------



  • 11.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 07, 2019 12:06 PM
    ​Thanks for commenting Mike.    There was no mention about changing the Query Timeout in SQL Server.    All I can comment on is the change to DBBuild.

    Best regards,
    Gail J-N

    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------



  • 12.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 11, 2019 06:37 AM
    We have moved several customers to Azure and the only performance issues were with printing and after tweaking that is was not an issue.  We do have some continuing issues with users and the session ids when trying to redirect pdf prints to their local printing functions or save locally but that is user education in most cases.

    One of the big pluses was that they were very cost conscious and you are able to set machines to auto turn off-on times which has saved them thousands as we run their production machines 6am to 7pm daily and shut down weekends.  This can easily be changed upon request for a weekend if necessary.

    during the initial setups, I did find copying large data files for SQL (most about 30-40gb) did take a bit longer but if I copied from our location with much faster upload speeds if was still much quicker so much of this will still depend on local internet access.

    ------------------------------
    David Callery
    Consultant
    Coe & Company, LLC
    marrero LA
    ------------------------------



  • 13.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted Feb 12, 2019 10:49 AM
    ​I'm been struggling through a review of security and our menu system because an upgrade is an ideal time to take a look at cleaning up that area.

    We do all of our security in discrete access rights groups that vary by company.    Each key task is in a separate rights group, and each user's role dictates which tasks they get.

    Currently, we have a single menu that approximates the  "EVERYONE" generic menu that ships with the product.    The EVERYONE menu contains all screens and is updated by the upgrade process.    Many years ago, realizing that this was the case, we made a copy of that menu I'll call "MAIN"  and began customizing that one instead.    None of the users get the "EVERYONE" menu; all users get the "MAIN" menu.

    In comparing the two EVERYONE menus between the two versions, the key change is that there is a new Approval Maintenance screen (21.420) that I need to be add to my custom menu and to various access rights.   This is the new screen to enable a rudimentary work flow in AP for the batch approval process.

    My use of a custom MAIN menu seems to have caused a problem in the upgrade that is experienced by only a few users according to tech support.  Namely, our MAIN menu was modified during the upgrade and now carries ~ 3,000 more records than it did before the upgrade.    In other words, the custom MAIN menu is hosed after the upgrade.

    No big deal - I just need to delete the "MAIN" menu in the V2018 system database's SLMenuItem table where owner = 'MAIN'.    I can export the menu from V2015 and import the menu into V2018 - similar to the process for porting customizations.

    Most users won't run into this, I'm told.    Users with more complicated usage of the menu system may run into it.   It seems to have something to do with the complexity of the menus you're using.

    There are two ways to use rights groups to create a menu:
    1)     Create a rights group that is only used in the Menu Maintenance screen and has zero screen rights assigned to it.    A user needs both an access rights group and a menu group to open and use a screen.
    2)     Create a rights group that used in both Menu Maintenance and also has access rights on it.    A user only needs the one rights group.

    What we've done with our MAIN menu is to create a MAIN menu that all users will see, and the menu display process leaves off menu items not found in the access rights table (i.e. option 1 above).    However, we also have some role based menus that we hung onto the access rights menus (option 2 above) for some specialized areas.

    The key problem I'm running into is that we have some specialized groups that are being rolled out to our many branch offices, and all of those offices have a separate database.    I don't really want to maintain menus in each of those databases because there is a separate set of rights groups for each database.

    The  other problem with that is that when  you have users with access to multiple menus, then the display of the menus can be a little weird.    What I have found is that the display for a particular user with, let's say, 3 screens will be based on the alphabetical sequence of the menu name.    So if my user's rights groups are CASHMGR (2), FINLSTMTXLT (2), and MAIN (1), then these display alphabetically.   The problem is that whatever is the first menu will open automatically, and that may not be the desired behavior.

    In the next version, I'm rethinking menus and I think I'm going to eliminate option 2 above.    This does mean that in order for a specialized user to have access to something, I'll have to add them to a rights group and a menu group.     But if I name the menus  MAIN-ALL SCRNS, MAIN-CASHMGR, MAIN-FINLSTMTXTL, then the displays should  be in the correct sequence for the user.

    It's a style thing.

    Best regards,
    Gail J-N

    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------



  • 14.  RE: Upgrading from V2015 FP1 to V2018 CU1

    Posted 7 days ago
    Hi Gail and all,

    Did you at any stage look at the "Azure SQL database" option as opposed to the "Run up a VM and install SQL Server on that machine" option?

    Reason I ask is that I have two clients doing this at the moment (one is an upgrade to 2018 and the other is a moving of on-prem servers to cloud staying with 2015) and they are both wondering if Azure SQL database is an option?

    I suspect not...it's not in the minimum system requirements, but if anyone has explored this I would be interested in your experience.

    Cheers,
    JD.

    ------------------------------
    John Deyell
    Business Consultant
    Adaptable Consulting Limited
    auckland
    ------------------------------



  • 15.  RE: Upgrading from V2015 FP1 to V2018 CU1

    SILVER CONTRIBUTOR
    Posted 3 days ago
    John,

    Unfortunately, Azure SQL Database is not compatible with the current Dynamics SL architecture - the company database(s) and the system database.  Azure SQL Database (pure PaaS) is designed to run queries against a single database. https://azure.microsoft.com/en-us/services/sql-database/


    There is a middle ground option, Azure SQL Managed Instance.  https://docs.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance
    I don't remember what features are ready in managed instances at this time, but they've been trying to get to full parity with SQL Server. Unfortunately, the convenience of a PaaS solution with this functionality comes at the price of $1,000-$1,500 per month for the smallest instance size.
    I'm hoping someone has the time and spare change to test this solution as it seems like there's actually a chance it could be supported by Dynamics SL when all the features are ready.

    ------------------------------
    Drew Skwiers-Koballa
    Director of IT
    Inside Edge CIS
    Eagan MN
    ------------------------------