Update rollup 2 includes all application and platform hotfixes and regulatory features that have been released for Microsoft Dynamics NAV 2013 R2 and includes hotfixes that apply to all countries and hotfixes specific to the following local versions:
Also, update rollup 2 includes Cumulative Update 1 for Microsoft Dynamics NAV 2013 R2.
Where to find update rollup 2
You can download update rollup 2 from KB 2913982 - Update Rollup 2 for Microsoft Dynamics NAV 2013 R2 (Build 35800).
The hotfixes that have been released since update rollup 1 are listed in KB 2913982. For a full list of all hotfixes included in the update rollup, see the following CustomerSource and PartnerSource pages:
For more information about update rollups for Microsoft Dynamics NAV 2013 R2, see Announcement of update rollups for Microsoft Dynamics NAV 2013 R2.
We are happy to announce that we have added support for using Microsoft Visual Studio 2013 (Professional, Premium, and Ultimate editions) to create and modify RDLC reports. This lets you use the latest version of Microsoft Visual Studio when designing reports for Microsoft Dynamics NAV 2013 R2.
To enable Microsoft Visual Studio 2013 support, you must install the hotfix from the Knowledge Base article 2907585. After the hotfix is installed, when you design reports from the Microsoft Dynamics NAV Development Environment, Microsoft Visual Studio 2013 is automatically used if it is available on the computer running the development environment; otherwise, Microsoft Visual Studio 2012 is used if it is available. There is no option to choose which version of Microsoft Visual Studio to use if both Microsoft Visual Studio 2013 and Microsoft Visual Studio 2012 are installed on the development environment computer. With regard to editing RDLC reports for Microsoft Dynamics 2013 R2, there is no functional difference between using Microsoft Visual Studio 2012 or Microsoft Visual Studio 2013, and RDLC reports that are edited with Microsoft Visual Studio 2013 can be edited later with Microsoft Visual Studio 2012 if needed.
the Microsoft Dynamics NAV team
// Copyright © Microsoft Corporation. All Rights Reserved.
// This code released under the terms of the
// Microsoft Public License (MS-PL, http://opensource.org/licenses/ms-pl.html.)
In our blog post How to: Validate that Microsoft Dynamics NAV 2013 R2 is correctly configured to support Single Sign-on with Office 365, we presented the Microsoft Dynamics NAV Best Practices Analyzer, a tool that you can use in order to validate your single sign-on (SSO) configuration of Microsoft Dynamics NAV. Not only does it validate your Microsoft Dynamics NAV and Windows Azure Active Directory (WAAD) configuration, it has another big advantage of assisting you in setting up your environment for SSO by providing meaningful and suggestive error messages which help you build your way through this lengthy process. The entire list of steps needed for setting up SSO with Office 365 in Microsoft Dynamics NAV is completely described in this how-to video.
In the previous paragraph I have just mentioned that this is a “lengthy process” which many times can become a rather unpleasant troubleshooting experience. We have collected this feedback and addressed this problem by providing the system administrators willing to set this environment up with a powerful Windows PowerShell cmdlet.
This cmdlet is called Set-NavSingleSignOnWithOffice365 and it can completely automate the process of configuring your Microsoft Dynamics NAV Web Client to support SSO with Office 365. For more information on the usage of this cmdlet and all the possible scenarios where its power can be leveraged, refer to the official Microsoft Dynamics NAV Help topic, which will be released with the next MSDN Library refresh: Walkthrough: Setting up your Microsoft Dynamics NAV installation for Single Sign-on with Office 365 using Windows PowerShell.
Note: The cmdlet can fully automate the configuration process provided that the needed parameters are specified when executing it. Generating and importing the security certificates that secure the Client – Server communication channel is performed separately and is subject to another upcoming topic with the next MSDN Library refresh: How to: Create a Self-signed Security Certificate Using PowerShell Script.
In the following section, you will find information about setting up your Microsoft Dynamics NAV installation for single sign-on with Office 365 using Windows PowerShell.
Microsoft Dynamics NAV supports federated user authentication with Windows Azure Active Directory (Windows Azure AD). This is the Identity Provider service used by Office 365. As a matter of fact, every time a new Office 365 subscription is provisioned, the Windows Azure AD tenant for this subscription is also created. Thus, when Microsoft Dynamics NAV is configured for federated authentication with a WAAD tenant, a single sign-on (SSO) user experience is achieved between Microsoft Dynamics NAV and the Office 365 Web Applications and any other applications that leverage the single sign-on capability provided by the Windows Azure AD tenant.
The Set-NavSingleSignOnWithOffice365 cmdlet can help you perform this configuration task by automating all the steps of this process. To sum up, this cmdlet performs the following operations:
Microsoft Online Services Sign-In Assistant for IT Professionals
Windows Azure Active Directory Module for Windows PowerShell
In order to run the Set-NavSingleSignOnWithOffice365 cmdlet, you first need to open Windows PowerShell as an administrator. This can be done by right-clicking on the Windows PowerShell program and choosing “Run as administrator”.
Then navigate to your Microsoft Dynamics NAV DVD, then to the WindowsPowerShellScripts\ NAVOffice365Administration folder.
Next, run the following cmdlet in order to import the NAVOffice365Administration PowerShell module:
Once the prerequisites are fulfilled and the Office 365 Administration module is imported, the sufficient condition for setting up SSO with Office 365 is satisfied by simply running the Set-NavSingleSignOnWithOffice365 cmdlet with the following parameter set on the computer that hosts the Microsoft Dynamics NAV components:
Set-NavSingleSignOnWithOffice365-NavServerInstance “ServerInstanceName” -NavWebServerInstanceName “WebServerInstanceName” -NavUser “YourNavUser” -AuthenticationEmail “YourOffice365Email” -NavServerCertificateThumbprint “SecurityCertificateThumbprint”
ServerInstanceName represents the name of your Microsoft Dynamics NAV Server instance. You can find the names for the Microsoft Dynamics NAV Server instances running on your computer by running the Get-NAVServerInstance cmdlet.
WebServerInstanceName represents the name of your Microsoft Dynamics NAV Web Server instance. You can find the names for the Microsoft Dynamics NAV Web Server instances running in your IIS by running the Get-NAVWebServerInstance cmdlet.
YourNavUser represents the name of your NAV User account.
YourOffice365Email represents the email address of your Office 365 User account. It is in the form firstname.lastname@example.org. This user should have administrative privileges.
SecurityCertificateThumbprint represents the thumbprint for the security certificate used for securing the Client – Server communication channel. For more information, refer to the “Prerequisites” section of this article. You can get the list of thumbprints for your certificates by issuing this Windows PowerShell command:
Get-ChildItem -Path "Cert:\LocalMachine\My"
Note: You can avoid providing this parameter if you already have your Microsoft Dynamics NAV Server configured with a security certificate. This applies to Microsoft Dynamics NAV installations in the Windows Azure environment, and other environments where any credential type other than Windows is active and functional.
Once the Set-NavSingleSignOnWithOffice365 cmdlet is run, a dialog box will open, requesting your Office 365 account user name and password.
This configuration type assumes that your Microsoft Dynamics NAV Server and Web Server are on different computers. This means that you need to run the Set-NavSingleSignOnWithOffice365 cmdlet on each of these computers separately with a different parameter set in order to correctly configure your Microsoft Dynamics NAV Web Client for SSO with Office 365.
To configure your Microsoft Dynamics NAV Server for SSO, you need to run the cmdlet with the following parameter set:
Set-NavSingleSignOnWithOffice365-NavServerInstance “ServerInstanceName” -NavUser “YourNavUser” -NavServerCertificateThumbprint “SecurityCertificateThumbprint” -SkipWebServerConfiguration
Notice the SkipWebServerConfiguration switch, which specifies that the Microsoft Dynamics NAV Web Server components should not be configured at all.
To configure your Microsoft Dynamics NAV Web Server for SSO, you need to run the cmdlet with the following parameter set:
Set-NavSingleSignOnWithOffice365-NavWebServerInstanceName “WebServerInstanceName” -AuthenticationEmail “YourOffice365Email” -SkipNavServerConfiguration
Notice the SkipNavServerConfiguration switch, which specifies that the Microsoft Dynamics NAV Server should not be configured at all.
Running the cmdlet fails because the NAV Server fails to start / restart
You can find more information about the Microsoft Dynamics NAV Server failure reason in the event log. This error most likely occurs because of the impossibility of the Microsoft Dynamics NAV Server to properly configure the ACL for the ports used by the server’s communication endpoints. In some situations, when there are URLACL entries for the same ports but reserved by other services (including other installed Microsoft Dynamics NAV Servers), the removal procedure fails because of insufficient privileges. The user account running the Microsoft Dynamics NAV Server needs to have administrative permissions for the modification of the URLACL to succeed. That is why, in order to overcome this issue, you can try one of the following:
Running the cmdlet in a multitenant Microsoft Dynamics NAV environment
Only one tenant can be automatically configured at a time, so the Microsoft Dynamics NAV Tenant name needs to be provided as the NavTenant parameter to the Set-NavSingleSignOnWithOffice365 cmdlet.
Avoiding the Office 365 Credentials dialog box
You can fully automate the script, and thus avoid the Office 365 Credentials dialog box by providing the credentials as parameters:
You use the AuthenticationEmail parameter to specify the Office 365 account email and the AuthenticationEmailPassword parameter to specify the Office 365 account password. Be aware that the latter parameter should be a SecureString.
Running the cmdlet for a Microsoft Dynamics NAV Web Server that is hosted in complex network topology
Setting the trust relationship between the Microsoft Dynamics NAV Web Client and Windows Azure AD requires specifying a remote endpoint for the Microsoft Dynamics NAV Web Client in the Windows Azure AD Service Principal that is created for this web application.
If the Microsoft Dynamics NAV Web Server runs behind a DNS or another network component that changes / rewrites the Web Client’s address, the Set-NavSingleSignOnWithOffice365 cmdlet is not able to compute this address, since it only runs on the local computer.
You can overcome this situation by providing the cmdlet the address as seen remotely for your Microsoft Dynamics NAV Web Client. The parameter you need to pass this address to is NavWebAddress.
The Microsoft Dynamics NAV Office 365 team.
In Microsoft Dynamics NAV 2013 R2, we introduce the ability to set up single sign-on (SSO) between an Office 365 account and a Microsoft Dynamics NAV 2013 R2 account. More precisely, the Office 365 user account is linked to a Microsoft Dynamics NAV 2013 R2 user account.
Implementing SSO requires that you correctly set up various elements, including a Windows Azure account for managing the Windows Azure Active Directory (Windows Azure AD) tenant, the Microsoft Dynamics NAV Server, and the Microsoft Dynamics NAV Web Server.
As part of a hotfix for Microsoft Dynamics NAV 2013 R2, we have provided an extension to the Best Practices Analyzer (BPA) tool. The extension can be used to validate the setup for your single sign-on application. The approach is as follows: you provide a simple set of parameters, and then the tool validates the setup to see whether it is correct for single sign-on.
This blog post describes the principles of single sign-on between Office 365 and Microsoft Dynamics NAV 2013 R2. It provides a short introduction to setting up SSO, information about how to use the BPA tool for validation, and a list of resources for additional information, including videos and Help documentation.
The authentication for SSO is handled by three parties. It is based on the first party being Office 365, the second being Microsoft Dynamics NAV 2013 R2 and the third party being the Windows Azure Active Directory (Windows Azure AD) service. Microsoft Dynamics NAV 2013 R2 trusts Windows Azure AD and Office 365 trusts Windows Azure AD, however, Microsoft Dynamics NAV 2013 R2 and Office 365 do not trust each other.
The Windows Azure AD is the identity management service for Office 365. The credentials that you use to sign in to Office 365 are the same credentials that you use to sign in to the Windows Azure Management Portal (http://manage.windowsazure.com). By definition, Office 365 trusts Windows Azure AD and if Microsoft Dynamics NAV 2013 R2 trusts Windows Azure AD, we indirectly establish a trust between Microsoft Dynamics NAV 2013 R2 and Office 365 by letting Windows Azure AD provide its trust to Office 365 to Microsoft Dynamics NAV 2013 R2. This is done in the following way:
To start with, we need to get the federation metadata from Windows Azure AD specifically for the given Office 365 subscription. An Office 365 subscription is an Office 365 account, which is sometimes referred to as an Office 365 tenant. We also need to let Windows Azure AD know about the Microsoft Dynamics NAV Web Server address. After providing the right information to Windows Azure AD, it knows enough about the Microsoft Dynamics NAV Web Server, but now Microsoft Dynamics NAV Web Server and Microsoft Dynamics NAV Server need to know about Office 365 and Windows Azure AD.
Microsoft Dynamics 2013 R2 is based on a multi-tier architecture. This architecture consists of an SQL Server, Microsoft Dynamics NAV Server, and the Microsoft Dynamics NAV Web Server. For SSO, we do not have to configure anything special on the SQL Server but we do need to modify both the Microsoft Dynamics NAV Server instance and the Microsoft Dynamics NAV Web Server instance configuration. The Microsoft Dynamics NAV Server must be configured to run in the credential type AccessControlService, and it must also know the URL for Windows Azure AD for retrieving the federation metadata. The Microsoft Dynamics NAV Web Server, which is hosted by Internet Information Services (IIS), must be configured to run in the credential type AccessControlService, and it must also know the path to the Windows Azure AD authentication endpoint. The final configuration setting is that each Office 365 email account has to be mapped to each user in Microsoft Dynamics NAV that is expected to use SSO.
For more details, see the references in the Appendix section.
With Microsoft Dynamics NAV 2013, we introduced the Best Practices Analyzer (BPA) to analyze the configuration of Microsoft Dynamics NAV Server and SQL Server in order to determine whether these components are configured correctly or not. In Microsoft Dynamics NAV 2013 R2, we have extended the BPA to include an analysis of the SSO configuration.
The BPA tool can be used by copying the BPA folder from the Microsoft Dynamics NAV 2013 R2 installation media (DVD) to your computer or by running the tool directly from the DVD. (Note: The DVD must be newer than November 25, 2013 – hotfix number 35727.) To run the BPA tool, we recommend that you copy the files to a local folder (if you do not need to use the Helper files you can run the tool from the DVD), enable Desktop Services, and then choose “Run As Administrator”.
To proceed with the BPA tool, we assume the following:
The BPA tool includes several steps that perform the analysis of your configuration. The following figure shows the Start a new Best Practices scan screen. The new analysis for SSO is enabled by choosing Yes for the “Would you like to verify that the environment is configured for Single Sign-On with Office 365”? option.
The parameters that you can set are described in the following table:
Active Directory Server
This is automatically determined and is optional.
Server Instance Name
This specifies the name of the Microsoft Dynamics NAV Server instance, which can be found under Services on the computer. In the example, the Server Instance Name is “DynamicsNAV71”
It is also specified in the Microsoft Management Console:
Web Server Instance Name
This specifies the name of the web server instance for the Microsoft Dynamics NAV 2013 R2 Web Client, which can be found in Internet Information Service (IIS) Manager.
In the example, the web server instance name is the name of the virtual folder under Microsoft Dynamics NAV 2013 R2 Web Client.
Microsoft Dynamics NAV Tenant
This is only needed in a multitenant environment – the value “default” is the name of the first and only tenant in a single tenant configuration
Office 365 User Account Email
This is the user name for Office 365 (and Windows Azure AD). This looks similar to admin@myO365.onmicrosoft.com.
When you have filled out the parameters, you choose Start scanning. Shortly after, you will get a request for the password for your Office 365 account so that the BPA tool can connect to your Windows Azure AD tenant in order to verify your configuration:
Within half a minute or so, the Scanning Completed message appears.
You then choose View a report of this Best Practices scan. (You can only see List reports if you have not enabled Desktop Services. Otherwise use Tree reports.)
The tool shows a number of errors. If you choose the first error in the list, then more details and some guidance are shown.
If you choose Tell me more about this issue and how to resolve it, then the documentation will open, where you can see even more guidance on what you need to do in order to fix the problems.
You can also see this information in the Tree Reports.
As you can see, this tool can be really helpful when you need to get through the configuration of SSO. You can keep the BPA tool open as you resolve problems, and once you are done, you can choose to scan again to see whether issues are resolved.
As a final check, verify that the SSO actually works. If it is the first time that you sign in, the credentials are needed.
With this extension to the BPA, we hope that you will have an easier time validating that Microsoft Dynamics NAV is correctly set up for single sign-on with Office 365. To get a better understanding, take a look at the references provided in the appendix.
References to videos
How Do I: Enable Single Sign-On with Office 365 in Microsoft Dynamics NAV 2013 R2 is available on MSDN and in the Microsoft Dynamics NAV Community.
More information about Windows Azure Active Directory
Windows Azure Active Directory
Manage Windows Azure AD using Windows PowerShell
More information about Microsoft Dynamics NAV 2013 R2
Authenticate Users with Windows Azure Active Directory
Users and Credential Types
Configuring Microsoft Dynamics NAV Web Client by Modifying the web.config File
How to: Configure User Authentication for the Microsoft Dynamics NAV Web Client
Configuring Microsoft Dynamics NAV Server
How to: Configure the Microsoft Dynamics NAV Web Client for ACS
More information about certificates
Eric Beran, Mike Borg Cardona, Vlad Precup, Steffen Balslev, and John Swymer - Microsoft Dynamics NAV Office 365 team.
The NAV Design Patterns Wiki site was announced in November, as a repository containing the first NAV design pattern descriptions, together with a call for contributions.
We would like to say “welcome to the team”, to our new design patterns authors. Their patterns are linked below. If you want to learn from the experience of other Microsoft Dynamics NAV partners and from some of the designs they have implemented or used, then read on.
By waldo at ifacto
Send information (parameters) to a processing framework/routine so that it knows what to do, how to behave, .. .
For a processing routine to behave correctly, it needs sometimes input of a user to know what it has to do, check or avoid doing. To do this, usually a piece of UI is getting called (STRMENU) with the question what to do. These input needs to get to the routine.
Continue reading on the NAV Patterns Wiki...
by Jan Hoek at IDYN
The Conditional Cascading Update pattern is used to intelligently populate fields whose values depend on other field values. In this pattern description, the field triggering the update will be called “source field”, and the depending field will be called “target field”.
The value of one table field sometimes depends on the value of another field, typically following an application-defined transformation (note that we're talking about transformations of field values here. This has nothing to do with e.g. form transformation), such as conversion to uppercase, removal of certain characters etc.
If the target field is non-editable, ...
Read more about Conditional Cascading Update on the Wiki...
The Setup Specificity Fallback pattern allows users to efficiently define a potentially complex setup in terms of rules and exceptions to these rules, exceptions to the exceptions, etc.
The pattern involves a setup table with a compound (i.e. consisting of more than one field) primary key, where each record in the table maps a combination of primary key values to a particular setup value. However, setting up and maintaining each and every combination could prove to be rather labour-intensive.
Read more on the NAV Design Patterns Wiki...
With best regards from the NAV Design Patterns team.
Update rollup 9 for Microsoft Dynamics NAV 2013 (Build 35782) has been released.
Update rollup 9 includes all application and platform hotfixes and regulatory features that have been released for Microsoft Dynamics NAV 2013 and includes hotfixes that apply to all countries and hotfixes specific to the following local versions:
Where to find update rollup 9
You can download update rollup 9 from KB 2913980 - Update Rollup 9 for Microsoft Dynamics NAV 2013 (Build 35782).
The hotfixes that have been released since update rollup 8 are listed in KB 2913980. For a full list of all hotfixes included in the update rollup, see the following CustomerSource and PartnerSource pages:
For more information about update rollups for Microsoft Dynamics NAV 2013, see Announcement of new hotfix process for Microsoft Dynamics NAV 2013.