Today: AX 2012 RTM CU3 running on Wndows Server 2008 R2 and SQL Server 2008 R2
Target: AX 2012 R3 CU12 running on Windows Server 2012 and SQL Server 2016
Reasons to upgrade the infrastructure...below are the comments from my company's DBA:
There is some big improvements
to SQL 2016 that we can take advantage of. One of the biggest changes is
the improvement to Query store. For a dba, performance tuning will get
easier. There are some big improvements to security and auditing along with BI
improvements. Since we aren’t running Enterprise version, we can’t
take advantage of the improvements to Always on, OLTP performance, operation
analytics, and in-memory tables.
With windows server 2012 we get
on a more updated platform, big improvements to remote desktop services, PowerShell management, and a host of other management features.
Keeping our platforms moving forward will continue to offer up improvements and new features offered up by Microsoft.
This is just to name a few reasons. Keeping up with your vendors on software and hardware versions always has its advantages. New features and enhancements are typically added to the most current releases. You sometimes have to push to get support and bug fixes to prior releases.
Below is a diagram from Microsoft's TechNet Library Scenario: Perform in-place upgrade to AX 2012 R2 or AX 2012 R3 [AX 2012]. This for the most part describes our current environment and our target environment, what's different is we have a few additional AOSs and the BI are not represented. On our BI server is where we have SSRS, SSAS, SSIS, Management Reporter and SharePoint (for Enterprise Portal).
We started our journey many moons ago as a background project. Background projects don't get much steam as everything else takes priority. So if you make the project official with a stated priority for your resources, the better off you will be!
When we started, the latest version out there was CU9. Here are the basic steps (I'm sure I'm leaving out many detailed tasks done by our system administrator, but this should give you the general idea):
Keeping our platforms moving forward will continue to offer up improvements and new features offered up by Microsoft.
This is just to name a few reasons. Keeping up with your vendors on software and hardware versions always has its advantages. New features and enhancements are typically added to the most current releases. You sometimes have to push to get support and bug fixes to prior releases.
Below is a diagram from Microsoft's TechNet Library Scenario: Perform in-place upgrade to AX 2012 R2 or AX 2012 R3 [AX 2012]. This for the most part describes our current environment and our target environment, what's different is we have a few additional AOSs and the BI are not represented. On our BI server is where we have SSRS, SSAS, SSIS, Management Reporter and SharePoint (for Enterprise Portal).
We started our journey many moons ago as a background project. Background projects don't get much steam as everything else takes priority. So if you make the project official with a stated priority for your resources, the better off you will be!
When we started, the latest version out there was CU9. Here are the basic steps (I'm sure I'm leaving out many detailed tasks done by our system administrator, but this should give you the general idea):
- Created new servers (DB, AOS, and BI) and installed SQL Server 2014. We'll upgrade to SQL Server 2016 later after we get compatible version software from our ISVs (one ISV will not be ready until 2017 Q2).
- The DB is completely empty - NO business data! It is truly like starting from scratch to build a new AX environment.
- We then refreshed this environment with a copy of our current production environment. Deinstall all application software - layer by layer from the outside in. First CUS, then VAR, ISV, and SYS. Then begins the rebuild.
- Then build the R3 code base. We installed vanilla AX, CU9, and compiled. Installed all hot fixes that we had applied in our environment. Next we installed each ISV model and compiled, then installed VAR models and compiled. And lastly, installed our CUS model and compiled.
- All along the way, as with any compile, we had to resolve any code conflicts. There were 3 main issues that we encountered:
- The main issue we ran into was - Microsoft and ISV removed or renamed an object that we referenced in our code.
- The second issue is element ids - Microsoft added some objects. When we loaded our CUS layer model, we had element id conflicts. Objects that we created in the CUS layer had the same element id as some of the new R3 Microsoft objects. We had to update our objects to a higher unused element id number. We will be creating a powershell script to do this in an automated fashion for future compiles.
- We also had a small bit of code merging to do with our CUS model due to changes in our VAR model from our implementation partner.
- We installed Management Reporter and SharePoint on the BI Server.
- At this point, we were able able to export a modelstore! This is now the beginning of our R3 compiled code base.
Then there are steps that splits the database into two as depicted in the diagram above. Surprisingly, we found out that the Business Data that is depicited in the above diagram contain everything from our R1 database however the AOT is not referenced anymore! The R3 modelstore that we built is now in the modelstore database.
We also had to publish all SSRS and MR reports. BI cubes were built and deployed. Client was set up.
Friday (January 6, 2017), the project team met and we provided the URL to our project team! They now have access to R3 with Planar data.
Whoopie!!!
Thanks for sharing your upgrade story about creating the environment! It's awesome to read about other people's experiences.
ReplyDeleteI just updated this post after speaking with our system administrator. He used the technet article for in-place upgrades (https://technet.microsoft.com/en-us/library/jj733502.aspx). I left out a very important and somewhat lengthly step. I inserted a step which is in blue font above, it is the now step 3. I'll be adding another post soon which will describe a BIG issue that we just identified yesterday! More to come...
ReplyDelete