Selecting your Dynamics CRM developer(s) setup

If you are ever involved in a very large CRM implementation project, one of the decision that you need to make early is how to setup/structure your development environments and workstations. Not that I think it’s not as import on smaller project, but it is more critical in larger project.

First let’s start by defining what I mean by a large project (this is a completely personal):

  • Large development team (4+ people)
  • Multiple complex customizations pieces (plugins/custom activities/JavaScript/HTML) and/or integration points
  • Project length: variable, usually 6-8+ months

Last year, I wrote about how to setup your Dynamics CRM/Source Control environment properly for Dynamics CRM projects. Today, I want to focus more on the Development Machines setup and what I have found to be useful for decision making process to set them up.

In the typical CRM project, you will find a Dev CRM organization used for doing system configuration and basic customization. Then, for plugin/JavaScript development, we typically recommend to have either a dedicated VM with CRM installed for each developer, or a dedicated CRM Organization. The reason why we make this recommendation is very simple: development Isolation.

When you are developing say a web site or a mobile app, you don’t deploy your content on the test server or device that everyone uses until it’s ready to be tested. The same applies for CRM. If you have a primary development organization, why would you want developers to deploy work in progress on a regular basis? Plus, if they are working on the same module, they might overwrite each other’s code all the time. The loss of productivity will be at two levels

  • Deployed code that’s not finalized will cause bugs and people won’t be able to continue working, test in the CRM organization normally
  • Developers will likely overwrite each other if they are working on similar or dependent tasks which will result in a major loss of time and productivity

Now that I have sold you on the development isolation idea, here is a list of pros and cons that will help you decide whether you should go the individual CRM Organization way or the individual VM + CRM route.

Individual CRM Organization

  • Pros:
    • Easy to setup
    • (possibly) Part of your corporate domain which makes the access easier for developer and possibly other people if needed
    • Provides isolation for development
  • Cons
    • Developers lack control over the servers (i.e. can’t do IIS reset or restart services etc.)
    • Depending on how powerful your infrastructure is, sharing CRM/SQL Servers with multiple users, the servers might be overloaded quickly and you find yourself with an issue related to sharing your server resources
    • Removes the ability to debug the old fashion way by attaching to IIS/sandbox/async processes
    • Ongoing maintenance of the CRM/SQL server(s) hosting the organizations

clip_image002

Individual VM with CRM/SQL installed

  • Pros:
    • Provides developer with great control over the environment in which they develop
    • Provide isolation for development
    • Provide isolation for Hardware utilization (depending on how VMs are setup)
    • Easy to setup (build a VM once, create a capture and provision on need)
    • All development tools can be installed on the VM and isolated from workstation
    • Easy to do plugin/custom activities debugging by attaching to IIS/sandbox/async processes
    • Easier to perform integration test in an isolated VM
    • Relatively light use hardware resource if the VMs are hosted on developers’ workstations
  • Cons:
    • Possibly Windows OS Server license issue (each developer needs one license)
    • Network configuration can be tricky depending on your environment or Enterprise context (e.g. accessing TFS from VM, expose VM to the internet)
    • Heavy use of hardware resources (especially if you have VM Host server(s))
    • Ongoing maintenance of the VM host server and VMs

SNAGHTMLec1ea7

It’s worth noting that individual VMs can be created on a host server or on developers’ local workstations (laptops or desktop). You may or may not decide to join the VMs to the corporate domain, you could even setup your development environment in the cloud on a Virtual Network which we have done multiple times including for my company. 

Lastly, as noted by Darly Labar, if your project is with CRM Online, running VMs locally will prevent you from having a same version of Dynamics CRM in your developer VMs (CRM Online and On-prem are very similary, but not the same and not always in sync). The same applies for the individual developer CRM organization unless you have a CRM Online Sandbox for each developer or other instances of CRM Online they can use for development purpose.

There you have it. The great thing is that you always have options. From there, it’s making sure you select the one that is appropriate for your needs.

If you need help and guidance throughout this process, feel free to reach out to us at SADAX Technology. We offer “Hour Bucket” packages from 5 to 30 hours for Dynamics CRM and Azure consulting services. Request a quote here!

 

Exchanging data between CRM Forms and IFRAMEs

One of the most common requirements when we add content in IFRAMEs or Web Resourses in CRM is to have the ability to communicate with the calling or source CRM form to perform all sorts of operation. This article explains how this can be achieved using the postMessage JavaScript messaging mechanism.

What does postMessage do?

It’s a JavaScript method which was initially created to facilitate cross-origin communication between web pages. There are often valid scenario in which we need to display a page from another website in a new window or in an IFRAME. That’s the easy part. The more complicated part is when there is a requirement to perform some operations on the source page based on a action that occurs on the external page in the new window or IFRAME.

In the example below, consider we have a contact form that displays an external page in an IFRAME. When a button in clicked in the IFRAME, information (example, a lookup value) is passed to the CRM form, the value is set on the screen and the form is saved.

Step 1 – Write methods for the CRM Form: Register Listener, Message Handler  

The code below contains two methods, the first one (RegisterListener) sets a method that will be called if the postMessage is invoked (UpdateContactLookup). 


SADAX.Contact =
{
   RegisterListener: function () {

     if (window.addEventListener) {
       window.addEventListener('message', SADAX.Contact.UpdateContactLookup, false);
     }
     else { // IE8 or earlier
       window.attachEvent('onmessage', SADAX.Contact.UpdateContactLookup);
     }
   },

   UpdateContactLookup: function (event) {

     var origin = "";
     if (event.domain) origin = event.domain; // IE
     else if (event.origin) origin = event.origin; // FireFox - Chrome

     if ("https://source" == origin) {

       if (event.data != null) {

         var entity = SadaxJSON.parse(event.data);
         if (entity) {

           var value = new Array();
           value[0] = new Object();
           value[0].id = entity.Id;
           value[0].entityType = entity.LogicalName;

           var lookup = Xrm.Page.getAttribute("sadax_referencecontactid");
           lookup.setValue(value);
Xrm.Page.data.save();
}
}
else
{
alert("This message has been posted by an unknown source ('" + origin + "', expected 'https://source').");
return;
}
} 
}

Step 2 – Register the listener on Form’s OnLoad event

image

Step 3 – Write Code for the IFRAME to post the Message from the IFRAME

After the business logic execution, the postMessage method is called on the parent CRM form as follows:

function SetContactLookup(entityReference)
{
   var entity = {};
   entity.Id = entityReference.id;
   entity.LogicalName = entityReference.entityType;

   window.parent.postMessage(SadaxJSON.stringify(entity), "https://source");
}

Comments / Wrap up

At step 3, using the postMessage on the window.parent will cause the SADAX.Contact.UpdateContactLookup method to be fired on the parent CRM form. Notice that the method receives an event object as a parameter. The content of the object slightly differs based on the browser being used (IE vs rest of the world). Mostly, you should pay attention to the event.domain or event.origin attributes. This is used to validate the website that posted the message is safe (i.e. the one you are expecting).

There is also an event.data attribute that contains parameters that are sent from one page to another. In this case, we are using a renamed JSON library to stringify our custom object types. Passing an object without stringifying it would work, but we found it didn’t work well in all browsers/version. The reason for the renamed JSON library is again browser compatibility reasons. If IE8 is out of scope for you, you probably do not need this.

Notes:

  • This also work for web resources opened in a different window using window.open or Xrm.Utility.openWebResource
  • IE8 doesn’t allow to postMessage to other windows, only to iframes.
  • I haven’t tried this in CRM Online so you can try it by yourself if need be.

Custom User Interface in CRM – HTML5/JavaScript or ASP.NET Web application?

Lots of times on CRM projects, we are required to build and display custom screens inside of Dynamics CRM. There are a lot of factors that come into play in the choice how we build these custom user interfaces. It is a very key decision to make because it can sets the standard technologies and tools that you use for custom screens on project (among other things). I thought I’d share some key points to consider in your decision making process to determine what technologies and tools to use.

The need for custom user interface

First, it is important to know and understand when it is required to build custom UI as part of your CRM solution implementation. As a wrote a few years ago, we sometimes find ourselves in situations where we can come up with a complex data model and we feel like the out of the box UI capabilities won’t be user friendly enough to drive user adoption. Situations like that create the need to build more user friendly interfaces to simply make people’s lives easier when they start using the CRM/XRM application. Some examples are

  • Custom calendar view for timekeeping
  • Tree view to display a complex hierarchy
  • Interactive Bing or Google maps views of CRM data
  • Editable grids
  • Complex grids with aggregates, grouping functionalities
  • Integrated views to other systems

And the list goes on. The needs are very different depending on the nature of the enterprise looking to implement a CRM/XRM solution.

Most common technology choices

From experience, I have seen a lot of custom screens built using the following tools/technologies:

  • Silverlight
  • ASP.NET / ASP.NET MVC
  • HTML/HTML5 + JavaScript + CSS

The screens are usually displayed in web resources or in an IFRAMES inside CRM on forms or as standalone modules (open from a button, display in sitemap area). I will not cover Silverlight since Microsoft announced its end of life and continued support for a few additional years, plus the world has started to move on.

ASP.NET / ASP.NET MVC

  • Pros
    • Flexible server side business logic
    • Easily integration with external systems (web services, databases etc.)
    • Can be very quick to develop depending on the requirements, expertise and accelerators (advanced controls provided by Telerik, Infragistics or others can speed up development time significantly)
    • Develop with a familiar programming language (C# + Visual Studio) – this of course depends on your development background
  • Cons
    • Requires the deployment and maintenance of a hosted web application
    • You have to deal with the weight of ASP.NET (ViewState, Postbacks etc.)
    • Not a great fit with CRM Online and cloud offerings in general (cloud deployment, cross origin web sites, integrations etc)
    • Required additional configuration in CRM + JavaScript to set the IFRAME’s sources (URL)
    • Effort for developing custom web applications is often under-evaluated

HMTL(5)/JavaScript

  • Pros
    • Usually, a much lighter solution and if done properly, custom UI components can be very responsive and provide great user experience
    • All components are in CRM Web Resources (html pages, JavaScript files, images…)
    • Custom screens are CRM Solution aware and there is no need for deploying and maintaining an additional web site on a web server
    • A definite plus for cloud based Dynamics CRM implementations
    • Can be very quick to develop depending on the requirements, expertise and accelerators (Kendo UI controls or others can speed up development time significantly; other frameworks like Knockout JS, Bootstrap can also be useful)
    • Leverage trending technologies and tools
    • Use any IDE you want (no obligation to use Visual Studio, even if you should J)
  • Cons
    • Possibly additional complexity if you need to display information from an external system
    • If not structured properly, JavaScript code can become massive and hard to navigate/maintain
    • For non-web developers, might be a steep learning curve
    • Need to establish good project structure and standards (e.g. use TypeScript or Script Sharp)

What else to consider?

There are other factors to take into account, some being specific to each organization. A few examples:

  • What is the expertise or your resource pool?
  • Do we have people to build and maintain what we deploy?
  • Are we in CRM Online or planning to move to CRM online?
  • Are we, as a company, trying to get into HTML/JavaScript more?

This is good food for thoughts for starters. If you want more guidance, feel free to reach out to us.

How to show SharePoint document list on main CRM form

When you enable the SharePoint integration for CRM, you get the ability to view a document list view by navigating to the document area on the form. Often, users want have this list of document available directly on the main form and not have to navigate to another page. Here is one way to do it, applicable for the “old fashion” SharePoint integration using the SharePoint List Component for CRM. It does not apply to server-based SharePoint integration with CRM. This is an unsupported customization, use at your own risk. 

What you need

  • SharePoint integration enabled and configured for the target entity (i.e. list component installed, existing SharePoint Site & folder)
  • an IFrame on the form
  • a way to get the full URL of SharePoint folder associated to your record (could be a field that you automatically populate on the entity with a plugin, could be retrieving the SharePoint Document Location records using JavaScript when for form loads, etc.)

How it works

When the document view is loaded, there is a URL pattern used by the system to display the list component with the documents:

http://sharepointdev/crm/crmgrid/crmgridpage.aspx?langId=en-US&locationUrl={document location url}&pageSize=250

What you can deduct from the URL above:

{SharePoint Root Site}/crmgrid/crmgridpage.aspx?langId={Language}&locationUrl={Document Location Url}&pageSize={Page Size}

Grabbing that Url with the correct parameters and pasting in browser will display the list of document for the target CRM record. In short, all you have to do is display that Url constructed properly inside an iFrame on your CRM form (see illustration below). Please note that this can have a performance impact on how quickly the form loads (this component can take longer to be loaded and displayed.

image

Code snippet

Javascript Method to load the content


var documentSiteUrl = ""; /* Find a way to get this information – can be read from a hidden field on the form. */
var parentSite = ""; /* Find a way to get this information – can be read from a hidden field on the form. */

if (documentSiteUrl == "" || parentSite == "") {
   return;
}

// Build document location URL - Set IFRAME target
var docViewUrl = parentSite;
if (!StrEndsWith(docViewUrl, "/")) {
   docViewUrl = docViewUrl + "/";
}

var userLanguage = "en-US";
if (Xrm.Page.context.getUserLcid() == "1036") {
   userLanguage = "fr-FR"
}

docViewUrl = docViewUrl + "crmgrid/crmgridpage.aspx?langId=" + userLanguage + "&locationUrl=" + documentSiteUrl + "&pageSize=250";

var documentIFrame = Xrm.Page.ui.controls.get("IFRAME_Documents");
if (documentIFrame != null) {
   Xrm.Page.ui.tabs.get("Documents").setVisible(true);
   documentIFrame.setSrc(docViewUrl);
}
else {
   Xrm.Page.ui.tabs.get("Documents").setVisible(false);
}

Developer Focus – CRM Solution Manager Review

I’ve been using the CRM Solution Manager for a few months now and I thought I’d provide some insights on the product in case you are considering making the investment.

What is it the CRM Solution Manager?

CRM Solution Manager is a productivity tool for CRM Developer that integrates with Visual Studio and Dynamics CRM. The idea is for a CRM developer who writes plugins, custom workflow activities, JavaScript and HTML web resources to be able to do his/her development and manage deployments of the development components to CRM all from Visual Studio in a user friendly way.

The product comes as a Visual Studio Extension file (.vsix) and currently supports Visual Studio 2010, 2012, 2013 and 2015, that means it very likely supports the version you are currently using (I really hope so!). There is a free 30 day trial available to try.

After the installation, when you run Visual Studio, you are presented with a screen to log onto CRM:


When the connection is completed, you can create your projects (Class Libraries for plugins and custom workflow activities, and Empty Web project for web resources). Once your projects are created, the fun can start.

Plugins and Custom Workflow Activities Development

For server side development, the tool brings a lot to the table.

If you have a class library project not linked to CRM or not containing anything at related to CRM, right clicking on the project will give you the possibility to either add the Plugin Assembly to CRM or create Proxy Classes.


For a Plugin Assembly that’s already linked to CRM, you get a menu that give you the ability do a little more:


  • Build and Publish: This will build the Project, and update or publish the Plugin Assembly in your the CRM Organization you are connected to
  • Add Proxy Classes to Project: This will open a window for you to selected the entities you want to generate proxy classes for, as well as other settings such as the path (folder in which you want the classes to be created/updates), and which naming convention you want to use for your entities and fields (Display Names or Schema/Logical names)


  • Edit Plugin Assembly Details: Allows changes to Plugins Assembly details such as Location, Isolation Mode. Also gives the ability to configure ILMerge for merging multiple assembles at build time. This is helpful if you are used to creating ILMerge post-build event all the time.


  • Edit Plugins and Steps: This will give you a screen that looks very similar to the Plugin Registration Tool with options to add plugins, register/edit/disable steps, add and edit plugin images etc. Basically you get the same content as the Plugins Registration Tool directly from Visual Studio


  • Download all linked Items from CRM: This option will force a download of all the items that are linked to CRM. In this case, we are talking about the Proxy Classes that were generated using the feature described above.
  • Update all items: This will update CRM with the content of the project, in this case, it will update the plugin assembly using the latest build

Worth nothing, all the configuration (linked items to CRM, CRM connection etc.) is saved in an Xml file that resides in your solution root folder. If you need and want to carry your CRM Solution Manager configuration across multiple environments and for multiple developers, make sure you include it in your source control (it is not done automatically).

Client-Side (JavaScript/HTML) Development

The experience is very similar with to what we get on the server side. Right clicking on the right button will give you a CRM option with a few options.


  • Add Items to Project: Given that it is a web project in this case, the items that can be added to the project are a bit different than what we had in the Plugin project. You can select a CRM Solution, and from there you can download the Charts, Images, JavaScript, Sitemap, Web Files (HTML), as well as generate JavaScript and TypeScript Intellisense files for selected entities.


  • The other options are similar to what we had in the section above:
    • Downloading all linked items from CRM will update all web resources by getting the latest version from CRM
    • Update all items will update CRM with the items in your Visual Studio project
  • Worth noting, individual web resource files in the VS project are linked to their CRM counterpart which means you can publish single web resources by right clicking on them in the VS project and selecting Publish file to CRM


Wrap-up

The Good

  • The product is really not too intrusive. It doesn’t add any project creation template that your solution becomes dependant on. It doesn’t create any additional cumbersome toolbox that you need to open to manage your CRM related operations (no point intended)
  • It is a HUGE productivity booster. One can easily get used to having proxy classes easily regenerated on demand, as well as JavaScript Intellisence. One can also really get used to deploying web resources and plugin assembly without opening CRM or the plugin registration tool
  • The support team is very reactive, I have received an answer to all my inquiries within a day
  • The product is being actively maintained and updated to support the latest versions of Dynamics CRM and Visual Studio

The Bad

  • If you are using CRM Solution Manager for specific things (e.g. creating Proxy classes and Option Set Enumerators), it means one of two things. Either all of your developers need to be equipped with the add-on in case the classes need to be regenerated  or the entire team dependent on one person to regenerate the entities classes when required. If you are the only developer on the project, it will work well for you. However if you are a consultant and need to hand-off the code when you are done, you may not want to us it to generate the proxy classes as people who will maintain the code might not have it to generate identical classes in the future.
  • The price point is a bit high. At $209.95 US per license (with volume pricing available), it is almost as expensive as some of the excellent and proven productivity tools such as Resharper ($300), Coderush ($250). That makes your development environment a bit expensive to set up. Pricey also considering there are free tools like the CRM Developer Toolkit (for which we are still waiting for a new version for VS2015, CRM 2015/2016), some of the tools in the XRM Toolbox and also the CRM Developer Extension developed by fellow CRM MVP Jason Latimer. The latter is a must try, the feature set is impressive and extremely complete! I haven’t had a chance to work with it yet but I will make sure to review it once I do.

All in all, I would recommend the CRM Solution Manager if you are an Organization with Dynamics CRM deployed internally with multiple developers writing code that targets the platform. If you are a solution integrator or a consulting shop, make sure you don’t create too much of a dependency with the tool, because your clients won’t necessarily have access to the add-on.

Hope this help!

For further questions and assistance with your CRM Development tools and environment, or other Dynamics CRM related inquiry, feel free to reach out to us!

 

Full CRM Deployment in Azure – Part II – Expose CRM to the Internet

In my previous post, I shared some of the chanllenges we faced as part of the deployment of a full CRM Infrastructure in Azure. In this post, I will focus on how we exposed the CRM application on the internet to meet our business requirements.

Context

Before I talk about the options and our decision making process, it is important to talk about some of the key requirements that we have for our application.

  • Dynamics CRM is the heart of the platform, containing client, membership info as well as open requests (you can think of these as cases)
  • Customer information is used/displayed through multiple portals (Adxstudio and custom portals)
  • Customer information is also used/displayed in custom mobile applications (not the Dynamics CRM apps), available in the Apple Store and in Google’s Play Store.
  • Internal support agents need to have access to CRM from anywhere in the world at all times (they have accounts in CRM)

One of the design decision that was made is to have a web service that the mobile applications can communicate with. That way, all our mobile applications use the same Data Access Layer to get to and manipulate Dynamics CRM data. The following diagram shows a simplified version of our architecture.

image

WIth that in mind, our portals and mobile applications have to be able to communicate with Dynamics CRM. To make that happen, we considered two options.

Internet Facing Deployment

That was our initial idea. We wanted to go with the classic IFD deployment for our Azure hosted Dynamics CRM installation. That would include the usual Claim-based authentication, ADFS configuration and a bit of advaned network configuration in the cloud service. In Azure, such a deployment isn’t very different from what we do for on premise-type installations. The main difference resides in how and where some of the configuration is done (certificates registration, DNS configuration done through Azure config using new portal or PowerShell commands).

Internet Facing Web-Sites hosted in Azure VMs 

The other option here, is to simply use the Azure VM End Points and Load Balanced Sets features to expose the CRM application on the web (internal or public). The big picture consists of having the CRM front-end role installed on multiple servers in our cloud service, create a load balanced set that exposes the CRM Web sites through an accessible URL (can be public or internal depending on your setup and requirements). The challenges here are authentication and possibly security (and they are not discussed in detail here, but happy to elaborate questsions are posted!).

image

What we did, how we did it and what we learnt

Now we are getting to the cool part. We decided to go with the second option, mainly because of expertise, ease of support and ease of deployment. It is much easier to find people who have basic knowledge of endpoints, load-balanced web site, than people who know CRM and IFD.

Untimately in our context, we needed to have a CRM that is accesible for our CRM users from anywhere in the world to our users. It also needed to be accesible from our Portals and custom web services all hosted in Azure.

Important to keep in mind that if you want to use the Dynamics CRM Mobile applications, ADFS is the required authentication mecanism so that factor into your decision making process.

Here are the main steps to getting to our goal.

  1. VMs are created, the Dynamics CRM Front-End Role is installed our two servers
  2. Validate CRM is accessible from both VMs independently using their local URLs (e.g. http://crmapp1/orgname and http://crmapp2/orgname 
  3. If all of that works, then it’s time to configure your VM end points and load balanced set

image

Looking at the Load Balanced Set above, we have created a web application available at “DNS Name” + Public Port. When the website at that URL is requested, it will be redirected to one of the CRM Virtual Machines on the port 80 which is the configuration you see with the VMs that are members of this Load Balanced Set.

image

When you reach your CRM, you will be prompted by the browser for user credentials (AD). There are multiple ways to enable single sign on but not discussed here. 

One resource that has been key for us in the process of making this happen is the Cloud Ranger blog and videos!

It’s been a fun experience. We love Azure more and more! To get more information and details on how you can build a full CRM infrastructure in Azure, or any information about your CRM needs and implementations, reach out to us!

Full CRM Deployment in Azure – Part 1 – Infrastructure

As part of a recent engagement, one of companies I work with made the decision to move from CRM Online to a CRM 2016 deployment in Azure. That includes full development and production environment virtual machines in Azure, and to take it even a step further, we need all of it to be internet facing (IFD) and connected to multiple Adxstudio portals. Sounds complicated enough? I thought I would share the main steps we went through, the reference (articles, resources) we used and some of the challenges we faced as well as the resolutions.

This post will be broken into 2 parts. The first one, this one, focuses on how we set up the infrastructure. In part 2, I will describe the steps required to configure IFD for CRM in Azure. Time permitting, I write about how we tied in our Portals in the equation.

Overall infrastructure architecture

In order to make this simple, I’ll discuss only our development environment. From an infrastructure standpoint, it is very standard. We planned to have two domain controllers (DCs), always good as a best practice in case one of the two isn’t available. We also planned to have a separate ADFS server, one CRM Server with all roles, and one SQL Server.

image

That all sounds simple enough. However, since we are working in Azure, there are a few things that are done a little bit differently than when you work within an on-premise environment.

Setting up your Virtual Network, Virtual Machines and Domain

For starters, we need to create a Virtual Network that all of our machines will belong to. Once we have that in place, we need to create the required virtual machines, an active directory domain, and join all our machines to that domain. To achieve this, you can follow the steps in the following articles:

These resources are key to get you started. A few key important steps here are worth mentioning.

First, in the process of setting up your DC, you will need to make sure you update the DNS server of your Azure Virtual Network to the domain controller. In doing so, you will lose internet access from your VMs because there is no public DNS server available. That can become a problem very quickly. To solve the issue, you need to add a couple of additional DNS servers to your Virtual Network configuration. These DNS Servers are are Microsoft’s public DNS servers: 169.62.167.9 and 168.63.129.16:

image

Second, after the machines have all been created, we noticed there was no name resolution even through all the VMs were part of the same Virtual Network. We were able to ping using the IP address but not the machine names (short or FQDN, no difference). So we ended up taking a couple of steps to solve that problem.

  • We made our CRM Application Server and SQL Server IP addresses static. There are two ways to do this. If you are familiar with PowerShell, start by installing Azure PowerShell, then in a PowerShell console, connect to your Azure subscription by following the instructions in the installation link, and use the Set-AzureStaticVNetIP command to assign a static IP address to your virtual machine. The other way of achieving this is to use the new Azure Portal. If you navigate to your VM’s IP addresses settings, you can set the Private IP address to be Dynamic or Static as shown below. Select the Static option (see screenshot below)

image

  • We manually added DNS entries for both our SQL and CRM VMs in our DNS Server. If you are not familiar with doing this, check out this well written article.

Third, we initially had only one Domain controller for various reasons. We realized there was often long delays for AD related actions to be available throughout the network (e.g. add a user to an AD group). We created another server, joined it to our domain, added the AD DS role and made it another DC in our domain. Our issues seem to go away after we added an second DC.

That’s it for now. Feel free to post questions if you have any!