A few years back we launched our first Dynamics application where one of the requirements was the ability to scan files that were uploaded by end users, whether from the Dynamics application or from Dynamics Portals. These documents would be uploaded to an Azure Blob Storage Container, and as they were uploaded copies to a separate quarantine container until they would be scanned.

At the time our options for a Virus Scan solution were limited. We had an On-Premise Virus Scanning McAffee appliance that was available to us, and we ended up with a solution that would check every few minutes if there were pending quarantined uploads, we would scan them and then move them from the quarantine container back to the clean container.

The below diagram is the high level solution that was implemented.

This solution worked fine when the traffic was not high, but we did experience at time of high traffic that it would not complete processing the files in the allocated time, and needed a separate solution. The heavy traffic was mostly experienced in the last few months during the COVID-19 pandemic where the amount of applications that we received were substantial higher.

We needed to find a solution to have a quicker turnaround. We have used the Azure Service Bus in previous projects to pass information between our Dynamics environment and our On-Premise servers, so this should work. We would change the process to handle this in real time. As the file is uploaded to our Azure Storage Container, we would immediately fire the Azure Service Bus.

I have written a few posts about Azure Service Bus in the past, so if you are interested in that implementation, click here.

This solution would call the Azure Service Bus listener as soon as the file is uploaded and sent to the Virus Scanner. We could also bypass the need of the quarantine container immediately and only send it there after the Scan if the file was infected. The diagram below shows the new solution.

As I mentioned that we are in GCC and there are a lot of limitations both from the list of available connectors and the implementations that can be done, but I wanted to address this as if it was done in a Commercial Cloud.

I noticed a couple of weeks ago that Microsoft announced the availability of a new Virus Scanner connector called Virus Total. I was not aware of other options but when I did some searching I encountered the availability of three connectors that have the capabilities of scanning documents (or document streams): Virus Total, Cloudmersive Virus Scan and Microsoft Defender ATP. This was great, it would simplify this logic.

Regardless of which Virus Scanner you are using, you will need to get an API key from the vendor of the Virus Scanning connector in order to establish a connector. Depending on your load of scanning the your cost can be free or cost you some money. I think most of these vendors offer about 4000 free scans a month.

If you are using Dynamics Portals or Power Apps Portals, you can upload your documents to either an Azure Blob Storage Container or SharePoint. The following flow executes when a new filter is uploaded to a SharePoint folder, scans the file for Virus and creates a CDS record with the Status of a Successful or Unsuccessful scan. Let’s review this step by step.

The first part is going to be our trigger. When a new document is uploaded to SharePoint (or Azure Blob) the flow will be triggered to get the content of that document. In case of SharePoint, the single step will provide us with the Content of the Document. If using Azure Blob, we will need an additional step to get the content of the blob based on the path of the file.

Next, we will call the Scan file for Viruses. In this case we used the action from Cloudmersive, but any of the connectors should work just fine for this.

After the scanning is complete we will add a condition to our flow that looks for the result from the Scan. The CleanResult will return True if there are no Viruses and False otherwise. We can then determine what action we want to do. Delete the file, move to quarantine container or folder, write a record, etc… Your choice. In our case I just wrote it to CDS.

That is basically it. You can add additional logic as you see needed, but this is all it takes. Again if you are in Government Cloud or your IT is blocking certain connectors this might not be the solution for you, but if you are able to implement this, it might save you a lot of trouble and headaches.

The post The Road to modern Virus Scanning appeared first on Aric Levin's Digital Transformation Blog.

That did not make much sense, so we had to do some investigation regarding this issue. The first thing that we tried to do is see if we were getting the same behavior using List records, and the results were the same. The List records action provided us the same attributes as we had in the Get record action. Now remember this is in Government Cloud, so we are using the Common Data Service connector and not the Common Data Service current environment connector where we can specify our list of select attributes.

Now we had to see if this behavior was the same in Commercial Cloud. I created a simple flow using the Get record action on the Account record and passing an Id of a record, and all the attributes got returned. This issue did not occur in commercial cloud with an identical test flow and the same data in both environments.

Of course, first thoughts … bug. Let Microsoft know. The problem is we need a quick resolution, and this does not seem to be something that we would get a resolution quickly. We are still waiting for the CDS Current Environment connector in GCC.

Now, we are getting to the workaround. What do we do? Build a custom connector? Doesn’t make much sense. Should be a quick way to handle this, and there is. We were going to use an HTTP connector.

In order to use an HTTP get action, we would be using a GET method passing the URI and Authentication information and calling the WebAPI directly. The screenshot below shows the required parameters in order to get this working.

We initialize the Authority, Tenant, Audience, Client Id and Client Secret of our instance in order to connect to the Web Api and then the results will allow us to get the address1_name value from the account entity as it is in our case.

The next action that we had was to create a lead. We use all the data from the Get record in addition to the address1_name field from the HTTPGetAddressName request. The screenshot below shows creating the new record from both the CDS Get Request and the HTTP Get Request.

The Location is a formula containing body(‘HTTPGetAddressName’)[‘address1_name’]

Hope this is helpful to anyone, though it seems that the CDS Current Environment Connector will be arriving to GCC and GCC High sometime soon. I don’t have any official statement yet.

The post Get Record CDS action missing attributes in Government Cloud appeared first on Aric Levin's Digital Transformation Blog.