Novedades del SII en 2018 ¡Adáptate a la versión 1.1!

Original URL…

El Suministro Inmediato de la Información (abreviado como SII) será actualizado el próximo 1 de julio en la que será su versión 1.1, la cual incorporará numerosas novedades que afectarán a algunas gestiones que deben realizar las empresas que requieren de su cumplimiento.

Una vez más, en Aitana os trataremos de ayudar en este cambio normativo explicando en qué consiste el SII, cuáles son sus requerimientos y qué es lo que cambiará en esta nueva versión que está a la vuelta de la esquina. Además, te presentaremos nuestra solución para adaptar tu ERP y cumplir con la norma automatizando todos los procesos posibles. De esta manera, podrás aportar toda la información necesaria a la Agencia Tributaria sin errores y ahorrando costes.

Tanto si ya conoces la normativa y tienes una solución para la anterior versión, como si todavía no estás cumpliendo con el SII y quieres saber cómo hacerlo, nuestro próximo webinario te sacará de todas dudas y te dará un camino claro para cumplir con las obligaciones del SII.


Extending the Outlook Add-in Experience in Microsoft Dynamics 365 Business Central and Microsoft Dynamics NAV

Original URL…

One of the showcase features of Dynamics 365 Business Central is the ability to use the product within Microsoft Outlook clients using Outlook add-ins. There are two add-ins that come out of the box with Dynamics 365 Business Central: The Contact Insights add-in and the Document View add-in.

From an email within Outlook, Contact Insights enables the user to go straight to the Contact, Customer, or Vendor Card that is associated to the sender or recipient of the email message. From there, information about the contact may be viewed or edited and documents may be created and sent directly in Outlook. Given an email that contains a document number within the body of the message, Document View enables the user to directly open that document within the context of the email message; from there, the document may be edited (if it is still a draft), posted, or emailed to the customer. Figure 1 shows the Contact Insights add-in opened inside of the Outlook web client.

That explains the default add-ins in a nutshell. But what happens if there is a scenario that is not supported by the default add-ins? That is exactly what this article is about – enabling new scenarios through new or modified Outlook add-ins for Business Central. To understand how to extend the existing Outlook add-ins or create new add-ins, we first need to understand how the Outlook add-ins work with Business Central. If you don’t care and just want to try creating an add-in yourself, feel free to skip to part two.

Also, the same steps apply to the Outlook add-in for Dynamics NAV, provided that your Dynamics NAV deployment uses either Azure Active Directory or NAVUserPassword as the authentication mechanism. For more information, see Credential Types for Dynamics NAV Users.

Part 1 – The Outlook add-in Architecture

In the simplest terms, an Outlook add-in is a frame that loads some web page. In our case, that web page happens to be the Dynamics 365 Business Central web site. There are three different pieces to the Business Central Outlook add-ins: the add-in manifest, the code that generates the manifest, and the code that handles the add-in session. The Outlook add-in manifest contains information about how to load the add-in. It tells Outlook what buttons should appear in the Outlook client, what text those buttons should contain, the images that should appear on those buttons, and, most importantly, what to do when those buttons are clicked. The code that generates the manifest is on the Business Central side. This code takes a manifest template (defined in a particular codeunit) and puts the correct strings, resource image links, and URLs in the manifest based on the system language and server configuration. This is an important point to understand – the manifest will look different depending on the tenant from which the manifest was generated and the language. The last component in this system is the actual code on the Business Central side that handles the incoming add-in session. This consists of a web page made specifically for the Outlook add-ins (OfficeAddin.aspx) as well as C/AL code that loads the correct page and record based on the incoming add-in context. The context contains information about the email from which the add-in loaded – such as: sender or recipient(s) of the message, the email subject, etc. This enables a custom experience depending on the contents of the email message.

Manifest File

Let’s dig into the manifest file first. You can take a look for yourself by jumping over to the Office Add-in Management page (Page 1610), selecting the “Contact Insights” row in the table, then clicking the “Download Add-in Manifest” action. This will prompt your browser to download the XML manifest file, which is what gets deployed to Exchange during the add-in setup step. There are two main pieces to the manifest file. The top portion is what describes the add-in itself. It contains information such as the name, description, and icon for the add-in. When you manage your add-ins in the Outlook portal, this is the information that will appear for the Contact Insights add-in.

The top portion of the manifest also contains the web address to load when a user launches the add-in from the horizontal pane. This is the single Business Central button right above the body of the email message that is shown in the first screenshot above, as opposed to the branded icons, which are add-in commands.

The add-in commands are defined in the VersionOverrides element. You can use this portion of the manifest to define different actions. In the Contact Insights add-in, we have a button that performs the default action as well as a menu button that contains several different actions for creating new documents for the contact in the email message. Each of the buttons in the Contact Insights add-in are links to the OfficeAddin.aspx page that specify a particular command as a query string that will get processed later by C/AL code. All of the strings related to the buttons as well as the URLs are defined at the bottom of the manifest file – within the Resources element. Figure 3 shows how the OfficeContext and Command query strings are specified in the button URL.

Manifest Generation

The Office Add-in Management page can be used to add new add-ins to the system that can later be deployed to a user’s mailbox or to the whole organization. To create a new add-in in the system, you must first write the manifest file for your new add-in. You can use either of the two default add-ins or the manifest in the example below as a reference. Just make sure to change the id of your new add-in. You’ll need to decide whether the manifest that you’ve built is deployable by itself or if the manifest needs to be customized at add-in deployment time based on the Business Central system settings. As an example of the latter, the Document View add-in manifest is generated at deployment time because the system puts information about the system’s number series into the manifest so that the add-in can recognize document numbers in emails. In most cases, however, the manifest could stand by itself.
Once the manifest is created, the add-in can be created in Business Central by clicking the “Upload Default Add-in Manifest” action in the ribbon of the Office Add-in Management page. This will create a new record in the table. Now, the system will pull the name, description, and version from the manifest and use those in the table. The “Manifest Codeunit” field is used to specify a codeunit that will make any deploy-time customizations to the manifest that you just uploaded. If that’s not necessary, it can be left as 0. At this time, the add-in could be deployed using the “Set up your Business Inbox in Outlook” wizard. For more information, see Using Business Central as your Business Inbox in Outlook.

Handling the add-in

Up to this point, we’ve only discussed the generation of the add-in, but nothing about what causes the correct Business Central pages to open once the add-in is launched. The whole flow can be described in these seven steps:

  1. Outlook loads the manifest for the add-in and loads the frame.
  2. The frame launches the URL specified in the manifest, which is the OfficeAddin.aspx page on the Business Central web server.
  3. OfficeAddin.aspx makes use of some of the Office JavaScript libraries to pull contextual information from the email item.
  4. This page then launches the Business Central client on page 1600 and passes the contextual information to the page as filters.
  5. Page 1600 wraps all the information it got into an “Office Add-in Context” temporary record.
  6. Page 1600 then passes this record to Codeunit 1630 (Office Management), which determines what to do based on the incoming context.
  7. The correct page is rendered in the client and shown to the end user.

I encourage you to look at the attached PowerPoint file to get a step-by-step diagram of this flow. If you would like to understand more about how this flow works and you have access to the code, I also encourage you to check out the code for the objects that are referenced.

Part 2 – Creating a new, custom add-in

Let’s walk through the end-to-end process of creating a new add-in. That means: writing the manifest, uploading the manifest into the system, writing the code to handle the add-in session, and deploying the add-in through the Business Central system.
In this example, we will be writing a new add-in that simply shows the company’s product list in Outlook. It will do this by launching the Item List page.

The Manifest

There are a few things we need for our new manifest: the add-in information (id, version, name, etc.), the icon url, and the url to point the add-in when the user launches it. All but the last one are straightforward. The actual URL to point the add-in is what is most important here. If this isn’t formatted properly, then the add-in will not work. Let’s look at how this add-in is formatted. See figure 4.

  1. This is the URL to your Business Central instance.
  2. The OfficeContext tells Business Central what add-in it needs to be concerned with. It is how BusinessCentral differentiates between the Contact Insights add-in, the Document View add-in, and any new add-ins you might create.
  3. This is the version of the add-in. It should be the same as the version at the top of the manifest file. Note: If these versions are not the same, your add-in will not load correctly.

Create the add-in in Business Central

Once your manifest looks correct, it’s time to upload the manifest into your Business Central instance. To do this, open the Office Add-in Management page and choose the Upload Default Add-in Manifest action. Browse to your manifest file on your machine and choose Open. Observe that a new row is inserted into the table that contains the same name, description, and version that was specified in the manifest file. For this demonstration, we will not be inserting any deploy-time settings into the manifest file, so we will leave the manifest codeunit as 0.

Handling the add-in request

We previously mentioned the Office Management codeunit (1630) and how it is responsible for deciding what to do inside of the add-in. There is a function inside of this codeunit called “GetHandlerCodeunit”, which looks at the HostType of the add-in (specified through the OfficeContext query string in the url – see Figure 4) and checks if that HostType is for one of the default add-ins.

It also has a publisher function that gets the codeunit number to run in the case that the host type doesn’t fit one of the default add-ins. We need to write a new codeunit that subscribes to this function and tells Office Management to run the new code we write. The codeunit that we write needs to have two things regarding this: first, the subscriber function that I just mentioned and second, logic in OnRun that does what we want, which in this case is show the Item List page. See figure 7 to see how to set the properties on the event subscriber in the new add-in handling codeunit.

We also need to add two more subscribers that will allow the add-in engine to get the Office Add-in record for our new add-in. Both of published functions are in codeunit 1652 – Office Add-in Management: GetManifestCodeunit and GetAddin. The resulting code should look something like figure 8. Containing the OnRun logic and the three event subscribers. Note that in figure 8 relies on two text constants:

  1. ProductListHostTypeTxt – This is the same value as the OfficeContext in the manifest, which in this case is “Outlook-ProductList”.
  2. AddinIdTxt – This is the Id of the add-in, which is the GUID that we generated and put in the add-in manifest. It is also the primary key of the Office add-in table.

All the pieces are now in place for our new Outlook add-in for Business Central. The only thing left to do is deploy it through the assisted set up wizard. Do that now and then launch your Outlook client. If you are using OWA (Outlook Web Access), you will need to do a hard refresh of the page so that the client can load your new add-in manifest that you just deployed. Now click on an email, and see that your new add-in is available in the email. You should be able to just click the Product List link to launch the addin and then see the Item list page.


This example was very simple, but you can use the same steps to do virtually anything you’d like with your custom add-in. In addition, you might have already figured out how you could change the default add-in functionality by changing the OfficeContext in some of the URLs in the manifest and then creating your own handler codeunit for the new functionality. There are essentially five steps that we took to create our own custom add-in:

  1. Create the manifest XML file for the new add-in that specifies an OfficeContext in the URLs.
  2. Upload the manifest in the Office add-in management page.
  3. Implement a new codeunit that will handle the add-in session for your specific OfficeContext.
    1. This codeunit must include the three event subscribers we talked about.
  4. Deploy the add-in to your mailbox.
  5. Launch it from your Outlook client.

Interesting C/AL Objects

PAG1600 – The entry point into Business Central from the add-in.

TAB1600 – The container for all the context-specific information that comes from Outlook.

COD1630 – The engine of the add-ins. All add-ins go through this codeunit when initialized, and all AL objects that need to access the add-in go through this codeunit.

COD1636 – This finds a contact/customer/vendor based on the email context and redirects to the appropriate card page.

COD1637 – This finds a referenced document number (Document View add-in) and opens the related page.

COD1642/1643 – These handle custom add-in manifest (XML) generation when deploying the add-in.

Upgrading to Dynamics NAV 2018 from Dynamics NAV 2013 or Dynamics NAV 2013 R2

Original URL…

If you want to upgrade a customer’s database from Dynamics NAV 2013 or Dynamics NAV 2013 R2, you may have noticed that the latest Dynamics NAV 2018 cumulative update does not have a direct path to upgrade from these earlier versions.

The solution is to upgrade to Dynamics NAV 2018 Cumulative Update 2, and then upgrade to the latest Dynamics NAV 2018 cumulative update.

For more information, see Upgrading to Dynamics NAV 2018, which has been updated accordingly.

We hope this helps those of you who have been confused about Dynamics NAV 2018 Cumulative Update 3, and we apologize for the experience you had. Going forward, please use the processes outlined in Upgrading to Dynamics NAV 2018.

What is Microsoft Dynamics 365 Tenerife, really?

Original URL…

The weather right now might not feel like it, at least in Europe, but Spring is just around the corner.  For the Dynamics community that means that Microsoft’s promised launch of the product codenamed Tenerife is rapidly approaching. But the most common questions I get is still: ‘What actually is Tenerife’? It is important that we all get an answer if the product is going to be successful, right?

Starting with the basics, and with the caveat that this based on my current understanding, Tenerife is Microsoft’s SaaS small to medium business administration solution. What does that mean? Would it help to add that it’s their below-enterprise cloud system of record ? What if I throw in that it’s their business application platform on which independent software vendors (ISV’s) should develop industry-specific solutions. Oh, I forgot to add that it’s the data store and logic engine to lots of the apps in Office 365 now as well.

Is it NAV?

Lots of other people will tell you it’s ‘NAV in the Cloud’. Dynamics NAV, since its acquisition by Microsoft in 2002, has grown into the most prolific (by user count, implementations, revenue, partners, ISV options, take your pick) of Microsoft’s Dynamics on premises “accounting plus” products. It’s been cloud ready since 2013 but has relied on the partner to host it. Tenerife is Microsoft providing that platform and software as a service. In fact, everything you need as part of the core offering for a simple, per user, monthly fee.

So it’s NAV isn’t it? Just a name change and online, right?

Yes, NAV has to be a good place to start understanding Tenerife, as it has the same codebase as NAV. That means the software Microsoft installs on their platform is the same that I could install on your servers on premises as we have for decades past. See it on screen and you’ll have to look very hard to tell if its NAV or Tenerife.

But to confuse matters, yes there are some differences. What follows is a list of differences I can recall, and that I know are not under NDA at time of writing.

  • Web client only, with apps for iOS and Android for both phone and tablet. But there is no Windows client, meaning the main desktop users are going to be using their browser of choice. For some existing NAV users this would be a critical blocker, but users that have only ever users the web client don’t see the issue. If it does prove a problem in the wider market, expect Microsoft to update and enhance the capabilities further, as I can’t see the technical problem.
  • It’s licenced by the new Microsoft CSP program, which means per named user, per month subscription. No concurrent user or upfront purchase or annual maintenance options for Tenerife. Some veteran NAV partners are concerned about the loss of margins on licenses, but Office 365 partners already working with this model may adapt more easily.
  • Subtle functionality changes caused by security concerns around running it as a true SaaS multitenant application. Access to files on the servers, for instance, .NET function calls, and even access to some system tables have been blocked off to developers to prevent any organisation being able to compromise another. If you’ve never used NAV I’ll doubt you’ll ever notice.
  • You can install apps or extensions directly from AppSource, allowing you to try out ISV options and quickly uninstall if they don’t do what you want. This is a key advantage that I wish NAV had. The ISV options for NAV should rapidly migrate to Tenerife, and that will provide a major strength that the product hasn’t had in quite the same way to date. A bigger and more accessible market should benefit both publisher and consumer.
  • It’s a later release of NAV. The development team’s ongoing work gets to Tenerife monthly instead of waiting for the annual release that you have with Dynamics NAV. That means a monthly email telling you what they’ve added or improved. I’m hoping that you’ll be able to test the new features in a sandbox or test environment before deciding when to implement, but it’s likely you’ll need to be within six months or so, of the latest release.

Tenerife is “full fat” NAV, not the “skinny NAV” of the Dynamics 365 Finance and Operations, Business edition that has been available in the US, Canada, and the UK, for the past eighteen months. Tenerife has not just financials and a limited set of supply chain functionality but advanced inventory, warehouse management, and even the option of discrete manufacturing and service management as well. There will be no functional areas in NAV that will not also be available in Tenerife.

What do you want it to be?

Those aware of the NAV product’s legacy will know that, while we all call it NAV, no two organizations deploy the same solution. They have installed ISV addons for their industry needs or they have paid a developer to change or add anything they thought they needed.

Tenerife promises to continue to allow that level of “per tenant” customisation via custom extensions. That means that the long-held trump card of NAV is coming to Tenerife.

For requirements that still can’t be met via extensions (I have found few, but that’s an article for another day) or for ISVs that have lots of needed legacy modifications to the core application, Microsoft will provide ISVs with a version of Tenerife on which they can deploy their changes to the core objects or logic via a programme called ISV Embed. That means that not all “Tenerife’s” are going to be equal. Buyers will need to be careful what they are signing up for when using AppSource or working with a Microsoft partner.

So it is an ERP system, right?

Maybe you noticed that I haven’t used the ERP tag yet. But yes, this is what I believe Microsoft intend to be their strategic small to medium business ERP platform. Last I heard, they will not recommend maximum user counts to restrict it within that SME segment. What the functionality does decides its suitability for any organisation these days, much more than any (increasingly hard to define) seat counts.

Targeting Everywhere, but strongest for midmarket

Sensibly, Tenerife is designed to fit the segment of the market where NAV has been strongest. No more targeting the entry level requirements that Microsoft initially talked about with Business Edition or even the “outgrown QuickBooks” segment that they ended up with. Yes, Tenerife can be used for both of those and the application simplification work in the past three years has made that more viable. But really, where it’s going to succeed or fail is with the midmarket business that needs an adaptable platform for its digital transformation and is prepared to invest time and effort to get it. In other words, it will compete where NAV and GP have performed well, for all this century to date.

And the next questions are?

What will it be called? Unconfirmed right now but it will be part of the Dynamics 365 brand. I’m also promised the name will be short so Dynamics 365 Financials and Operations, Business edition is officially not going to happen. It won’t be called Enterprise, so make your own guesses and I advise you to watch the tweets from Directions Asia in mid-March.

What will it cost? Again, not announced but probably more than the $40/user/month that Business Edition costs. And with the talk of options for manufacturing, you can deduce there will be a range of prices. If you end up on one of the “cloud ISV embed” versions, expect to pay more.

What does ‘Spring’ mean? When it’s ready hopefully. The last thing we need is another change to the launch schedule. Don’t let your cynical side tell you that the last day spring in Denmark is 21st June so expect it then. You might well get a surprise. Again, I expect more public announcements at Directions Asia.

Will it replace the current Business Edition? Yes, current users will be upgraded to Tenerife I believe, and they are “making the commercials work”. That means that if you are considering it, I’d sign up for a couple of users on Business Edition now. It seems like you might get Tenerife for the price of BE. (What’s the keystroke for a winking emoji?)

Will NAV users be forced to Tenerife?  NO, NO, NO, for goodness sake how many times do you have to be told?! Microsoft makes a stack of money, even for them, out of the on premises NAV base and it would make no sense for them to threaten that. They assure me they will keep selling NAV licences for as long as you want to buy them and given they have just sold a 2009 classic licence to one of my customers this week (don’t ask why please), I believe them. Actually, I think it might be partners who stop selling it rather than Microsoft.

Dynamics NAV will continue? Yes, the single codebase means the cost of progressing NAV is negligible – or they get Tenerife almost for free, depending which way you want to look at it. There will be some change though. My bet is that they might change the name to match up with Tenerife – so Dynamics 365 Business On Premises, for example. I also think it makes sense that future on premises versions have named user and CSP licence options. With the Office 365 authentication we have now, that should be easy and means if you want to run on Microsoft’s ISV platform, on Azure, or on your own servers, it’s a technical choice about which platform is right for you, not a commercial or dogma based one.

Will Tenerife be successful? The most difficult question yet and definitely just my opinion at this stage, but yes I think it will. The conversation is about to flip from ‘why would I buy this’ to ‘why wouldn’t I. Sure, some people out there will say, you’ve haven’t got this feature yet or its doesn’t allow that, but people still point to classic NAV, now ten years old and say it was better at this or that. The Tenerife I’ve seen is good enough in all the key areas and has significant advantages in several. That, for me, should mean that if we give it a couple of years it will be the default shortlist option that NAV is now.

In fact, the biggest threat is the same one with which this article struggles. Tenerife can be so many things, how do the Microsoft product marketing team actually explain, in simple, language what it is? It might suffer from the curse of being able to hit so many targets, that it hits none. It would be tragically ironic if such a capable solution failed, because it was too flexible.

What I am certain of is that Tenerife is about to act like the erupting volcano its namesake was in years past, shaking the whole market as it stands. Whether you can successfully colonise the resulting landscape or are buried like Pompeii, is going to depend on how fast you evolve and adapt.

Converting Dynamics NAV source code from C/AL to AL using PowerShell

Original URL…

Converting from C/AL to AL can be a bit of a hassle:

  • First you need to open den Development Environment
  • Then filter the objects that needs converting
  • Export the objects to a txt file in a folder
  • Then Run the Txt2AL.exe
  • Lastly import them in the workspace

The Script can be downloaded here:

How to Download a Microsoft Dynamics NAV License from CustomerSource

To download a Microsoft Dynamics NAV license file from CustomerSource, follow these steps:

  1. Log in to CustomerSource.
  2. Click My Account
  3. Click Product & Service Summary
  4. Click Registration Keys
  5. Select the desired version in the Request and Display License Keys For Version field.
  6. Click Display License Keys.
  7. On the Request License Keys page, select Download License/Registration Key.
  8. Click Save in the File Download dialog box, select the folder where you want to download the license file to in the Save As dialog box and then click Save.
    Note: Do not open the license key before saving it as this may cause problems when you implement the license file.

SII – Cumulative Update 51 for Dynamics NAV 2013 R2

  • If you open the XML files from the SII interface, Internet Explorer cannot display the file because of a NULL value at the end of the file in the Spanish version.
  • SII notifications are automatically sent to the My Notifications part in the Spanish version.
  • The ImprteTotal value is incorrect in the SII interface if you issue a sales or purchase invoice of type F2 in the Spanish version.
  • Incorrect SII XML format in the Spanish version.
  • All documents sent through SII fail in the Spanish version.

Dynamics NAV – SII – Licensing

Electronic VAT information under SII – Suministro Inmediato de Información for Microsoft Dynamics NAV
Refresh your license to access the new objects that are added with this release. More…


This update is provided in the following cumulative updates for the different versions:

    • Cumulative Update 57 for Microsoft Dynamics NAV 2013

    • Cumulative Update 50 for Microsoft Dynamics NAV 2013 R2

    • Cumulative Update 38 for Microsoft Dynamics NAV 2015

    • Cumulative Update 26 for Microsoft Dynamics NAV 2016

    • Cumulative Update 13 for Microsoft Dynamics NAV 2017

Success Story | Anveo Service App for Noesse Datentechnik

Original URL…

NAV on Docker version

Original URL…


Some of you might already know what lies behind this cryptic title, some of you might not care. This post describes what changed in the Generic image version, which today is the foundation of all images on the Docker hub and of course also of the generic image on the docker hub.

Support for database credentials

The biggest visible change is the support for specifying database credentials and allow to easily setup NAV to use external SQL Server. In the end, this change was only a few lines of code, which was already described in the how-to document. Primary reason for not including these in the very first version was that back then, we didn’t have a secure way of handling credentials, meaning that credentials for your external SQL Server would be available for grabs by anyone. Today passwords are handled securely and database credentials can be transferred safely.

Note: You need to use databaseSecurePassword (or the navcontainerhelper) in order to safely transfer credentials.

Ability to run NAV 2013, NAV 2013R2 and NAV 2015

After launching NAV on Docker, one of the requests we got a lot was support for older versions. As described here, we do not support older versions, but with we allow you to run older versions on Docker. The reason for doing this is, to allow people to create an infrastructure which will allow developers to develop and test on newer versions like NAV 2018, even though they might be working on a customer project on NAV 2015. It also becomes much easier to test out a NAV 2015 customers solution on NAV 2017 because you can spin up any version in minutes.

So, we didn’t add this only to make it easier for you to work on NAV 2015 or earlier versions, we want you to move forward and we think this makes it easier.

Split installation and runtime scripts

The biggest change however is clearly the refactoring of navstart.ps1. In the first versions of the generic image, navstart was a multi-purpose script, which would do the installation if needed at the same time as starting NAV. While this was fairly simple in the beginning, it soon became complicated as more and more functionality was added.

With the requirement of being able to install earlier versions than NAV 2016 it became evident, the installation scripts needed to be separated from the running scripts. The installation scripts can still be used “on-the-fly” when running the generic image, meaning that the functionality really didn’t change a lot.

In order for you to understand how the NAV on Docker image works, I have created a small walk-through of what happens when you start a NAV on Docker image. This covers both the Generic image (microsoft/dynamics-nav:generic) and the Specific images (with a specific version of NAV installed ex. microsoft/dynamics-nav:2017-cu5-dk).

The source for the NAV on Docker images is available on github under


When starting a NAV on Docker image, the primary entry point is c:\run\start.ps1 and on a high level, this is what start.ps1 does.

  1. If not NAV is installed?
    1. If not C:\NAVDVD exists?
      1. Fail
    2. Copy the content of the version folder (c:\run\90 for NAV 2016) to c:\run
    3. Launch c:\run\navinstall.ps1 (or rather c:\run\my\navinstall.ps1 if it exists)
  2. Include c:\run\HelperFunctions.ps1 (or rather c:\run\my\HelperFunctions.ps1 if it exists)
  3. Run c:\run\navstart.ps1 (or rather c:\run\my\navstart.ps1 if it exists)
  4. Run c:\run\mainloop.ps1 (or rather c:\run\my\mainloop.ps1 if it exists)

In the github repo, you will find version folders for NAV 2013 (70), NAV 2013R2 (71), NAV 2015 (80), NAV 2016 (90), NAV 2017 (100) and NAV 2018 (110).

The my folder does not exist in the image by default, the idea is, that when running the image you can share a folder from the host to the c:\run\my folder and override functionality as you like.


navstart is the main runner for starting the image and it will sequence a number of other scripts, which all have a specific purpose. When sequencing these scripts, navstart will check whether the script exists in c:\run\my and launch that instead of the original script. This allows you to override the scripts and determine whether or not you want the base functionality or totally take over.

Two variables will be calculated in the beginning of navstart:

$restartingInstance will be set to true if this is a restart of the container. If this indeed is a restart, there are a number of things that can be omitted (setting up the Web Client, importing license file, creating users)

$newPublicDnsName will be set to true if the publicDnsName of the container has changed, either by this being the first time you run the container or if a restart caused a new PublicDnsName (happens if you use docker commit to create your own image and clone that).

The sequence of the various scripts are as follows:

  1. Include HelperFunctions.ps1
  2. Run SetupVariables.ps1 to read all parameters from environment variables into PowerShell variables and doing defaulting etc. SetupVariables will also decrypt encrypted password transferred to the container and remove the encryption key if requested, leaving the secure passwords as temporary securestrings only.
  3. If the user did not accepted the EULA, fail
  4. If the image is outdated and the user did not accept to run outdated images, fail
  5. Start SQL Server Express if $databaseServer is localhost
  6. Start Internet Information Server unless you requested no WebClient and no http download site.
  7. Run SetupDatabase.ps1 to setup the database. This will by default do nothing if this is a restart, restore a bakfile if requested or setup database credentials for external SQL Server access if databaseCredentials have been specified.
  8. If $newPublicDnsName
    1. If using SSL
      1. Run SetupCertificate.ps1 to setup a self-signed certificate. Override this to use a trusted certificate.
    2. Run SetupConfiguration.ps1 to setup the configuration of NAV (customSettings.config, port ACL’s etc.)
  9. Run setupAddIns.ps1 only if this is not a restart.
  10. Start the NAV Service Tier
  11. Run SetupLicense.ps1 if you are using a local SQL Server. It is assumed that license is in place if connecting to an external SQL Server. Default behavior for SetupLicense is to do nothing if this is a restart.
  12. If $newPublicDnsName is true and you didn’t skip the WebClient
    1. Run SetupWebClient.ps1
    2. Run SetupWebClientConfiguration.ps1
  13. If not restarting
    1. If you didn’t skip the Http Download site
      1. Create Web Site
      2. Run SetupFileShare.ps1
    2. Run SetupWindowsUsers.ps1
    3. If using Local SQL Server (it is assumed that SQL and NAV users are in place if connecting to an external SQL Server)
      1. Run SetupSqlUsers.ps1
      2. Run SetupNavUsers.ps1
  14. If ClickOnce is requested (and you didn’t skip http download site)
    1. Run SetupClickOnce.ps1 which in its default implementation will run SetupClickOnceDirectory.ps1 to setup the files to include.
  15. Run AdditionalSetup.ps1 which by default is empty, but allows you to do additional setup at the very end of the setup.
  16. Write container info output
  17. Run AdditionalOutput.ps1 which by default is empty, but allows you to write additional output to the user
  18. Write “Ready for connections!”

There you have it. It might seem complicated, but it offers extreme flexibility and you can really hook in a lot of places and change the behavior of small things if you need to.