Brown's Notes

As I've mentioned, I make it a practice to secure as many services as possible using SSL over HTTPS and, whenever possible, I'll use friendly URLs to make it easy for support staff and users to find and remember those services. This article looks at configuring multiple SOAP services on the same Dynamics NAV 2018 application server, where I've got multiple tiers used for their respective third party applications (such as Jet Professional or other ISV products), and how service principal names (SPNs) play a vital role in properly configuring a SOAP service using SSL and a friendly domain name. It does this by following the configuration of a Dynamics NAV SOAP service on a tier dedicated to a WMS ISV integration. A little background info... Configuring the NAV service account properly in the first place is a prerequisite for this article. An article from Microsoft, Provisioning the Microsoft Dynamics NAV Server Account , provides an excell

When working with Dynamics NAV ISV applications, you'll routinely be asked by vendors to expose NAV's SOAP service to the internet. This should make you feel uncomfortable. Thankfully, leveraging the Azure Active Directory Application Proxy makes this much more secure, and saves having to configure any additional infrastructure on-premise which may require thinking about DMZs and unruly firewall rules. A little background info... If you aren't familiar with Azure's App Proxy service, see my post about configuring it for general web applications here . It's a good introduction to it. This article goes on to assume that you have a functioning Azure AD App Proxy connector service running in your environment. I'll also make the assumption that you have a Dynamics NAV 2016 or newer service tier configured with an SSL certificate thumprint installed such that SSL can be enabled on the SOAP services. ...and A note on SSL...

Extensions for Dynamics NAV were released in NAV 2016, and were touted as a way to extrapolate all customizations out to an additional layer, leaving NAV's base code in tact and a nice, tidy and easy-to-upgrade platform. With the addition of events (which are fantastic), this sounded terrific and my development team and I were excited to get started with them. However, there are some serious limitations with extensions, and it's critical to be aware of them before starting down the road of heavy NAV development, as they can leave you with a tangled, virtually unmanageable mess if not kept in check with a clear plan of how best to employ them. The major one by far - and the subject of this article - is the poor design around field dependecies and customers' ability to make any changes to an extension "app" that any other app is dependent upon. In short, you won't be able to without first uninstalling any dependent app in orde

Giving external access to on-premise applications has typically required opening various "holes" in an organization's firewall. This practice has always made me shiver - even when using the web application proxy sever roles included with Windows Server OS's. Now, I am absolutely in love with the Azure Active Directory's (Azure AD) Application Proxy which is super-easy to configure, secure and, certainly for web apps, avoids ever having to punch holes in firewalls again. In this article I describe how I configured an on-premise web application for external access using the Azure AD Application Proxy utility, in combination with various DNS zone rules both external and internal. Technical Background First off, I would strongly encourage you read up on Microsoft's introduction to the Application Proxy , along with how the Connectors work. With that, though, I will provide some snippets from those articles which rapidly communication the power of the Azure A

It can be easy to become jaded as an IT support professional. It starts by finding yourself in a negative headspace - particularly on "those" days when stress levels are already be running high. You know what I mean. Your (hopefully) inner voice responds to support requests with gems like "what's he doing now?", or "Seriously? Again?". We've all been there. We all know some users that, upon the bits and bytes of their email cramming themselves into our already over-bloated mailboxes, cause an instant rise of internal temperature... This, in most cases, is a natural and understandable response. It's certainly the easiest response. It should be obvious, though, that it is not only entirely unacceptable in a professional work environment, but utterly destructive to the organization. Why is this so important? Because negativity spreads like a contagion. This is especially so when it originates in departmental (and organizational) leadership wher