The Microsoft Dynamics NAV 2013 Administration Shell allows you to run scripts implemented using PowerShell 2.0. There are predefined commands (called Cmdlet) that the user can use right away. The built-in Cmdlet allows the administrator to configure and troubleshoot permissions and connection problems on a local or remote computer. Also worth mentioning is that Cmdlet should always be run as an administrator.

This tool will come in very handy if you're deploying Dynamics NAV to remote locations or in your own private cloud.

As the name suggests, this is where NAV developers come to create all sorts of wonderful things for Dynamics NAV. This is the main environment where developers work; it is called the Client/Server Integrated Development Environment (C/SIDE). Within C/SIDE, you will be developing using a language called Client/server Application Language (C/AL).

All of the objects are contained within this environment and stored in the SQL Server database, so you do not have to go anywhere else to create or modify applications for the end users. Even the development of report layouts, which uses Visual Studio and not C/SIDE, is tightly integrated and is launched from within the development environment.

The development environment is also where the user can update the license either on the server or for their particular session.

When you start this application, it will look very empty. For Dynamics NAV developers, the majority of their time will be spent here, so having a nice clean space is a very good start.

Microsoft Dynamics NAV 2013 Windows Client is the actual client application that the end users will be using to transact their daily operations. As mentioned earlier, the client application is called the Role Tailored Client (RTC), or Windows Client.

By default, when you start the Windows Client, you will assume the role of a sales-order processor. This is okay, because you can still access any part of the system as long as you have permission to do so.

Any changes we've made in the development environment will be reflected in the client application through the middle tier. If you're using any other interface, such as a mobile interface or a web interface, the changes will be reflected there as well.

Do not confuse this with the previously mentioned Administration Shell. The Microsoft Dynamics NAV Administration program allows you to manage the Dynamics NAV services that are installed both on your local computer and on the server. You can also manage the services without using this program using the command prompt, but that wouldn't be very efficient, or fun.

There's a tool in the SQL Server 2012 folder called Import/Export Data. As a general rule, when working with Dynamics NAV or any ERP software out there, do not ever try to import data directly into the SQL tables in your ERP software. The reason is that these import/export programs do not validate against any business logic that's built in place. By doing these imports in an external program, you risk undermining the integrity of the data in your ERP software.

The SQL Server 2012 report builder is installed primarily for the API to upgrade RDLC 2005 for Dynamics NAV 2009 to RDLC 2008 in Dynamics NAV 2013.

Of course, you can use the report builder to create beautiful reports for Dynamics NAV if you do not wish to use the reporting tool within C/SIDE.

The reports that you will be modifying or creating in C/SIDE will automatically be linked to the appropriate objects. However, the reporting in C/SIDE will not be done using the Report Builder application.