One of the things I’ve been finding very confusing is the VPN Gateway sizing. Especially the mismatch between the pricing table and what the systems show you. Here’s the technical information:

Source: Azure.com: About VPN Gateways The same table is more or less available on the pricing page as well. There you can clearly see that the price difference is real. Pricing goes from 0,0304€ over 0,1603€ to 0,4133€/GW hour. As a VPN Gateway runs 24/7 this might have an impact on your bill. Pricing Source From a technical point of view both basic and standard offer the same features/performance for NON Express Route VPNs.

Conclusion #1: If you don’t need Express Route, there’s no difference between Standard and Basic.

Now what was bothering me: in many blogs/documentation people explain how to change the Gateway SKU. They always mention Default or HighPerformance. When you create a Gateway from the “old” portal this is how the resulting Gateway looks in PowerShell:

As you can see the GatewaySKU is Default. Now it might be just me, but how the hell on earth are we supposed to know what value default is? Luckily there’s a place like Azure Advisors on Yammer where get to ask questions like this. The Microsoft PM’s do a great job of helping is out and gathering feedback on various topics. The answer I got there is: Default is the same as Basic. Which does make sense in a way as we initially had either Basic or HighPerformance. But it does suck a bit that instead of using a default value they are setting default as a value. If you catch my drift…

Here’s the PowerShell cmdlet reference for the New-AzureVNetGateway cmdlet There you can see that the PowerShell cmdlet takes Basic, Standard and HighPerformance as parameters for the GatewaySKU parameter.

Conclusion #2: Default SKU == Basic SKU

Another area that might confuse you is how the new Portal displays the Gateway sizes. For all types (basic, standard and high performance) a size of Small is shown. Lucian also mentions this on his blog: blog.kloud.com: Azure VNET gateway: basic, standard and high performance But I must admit that I haven’t looked into this. I primarily cared about sku vs pricing.

I ran into another issue after upgrading a FIM 2010 deployment to MIM2016. As part of the OS/Infrastructure refresh I moved the database to a more recent SQL server platform. One of the things I initially forgot but found out pretty quickly is that obviously I also needed to update the FIM Management Agent parameters so that it points to the new database location. However when I clicked OK, I got the following error:

In words: Failed to connect to specified database. Failed to connect to the specified database with the given credentials.

And in the Forefront Identity Manager Management Agent event log (on the FIM Sync server):

In words: mmsmafim: MIIS.ManagementAgent.ManagedMACredentialFailureException: Failed to connect to the specified database with the given credentials.
   at MIIS.ManagementAgent.RavenMA.UIValidateCredentials(String pszCredentials, Int32& pfValid, String& ppszResult)

Upon looking a bit deeper I found the following error in the SQL Server logs:

In words: Login failed for user 'CONTOSO\FIMSYNC'. Reason: Failed to open the explicitly specified database 'fimservice'. [CLIENT: 10.x.y.z]
Error: 18456, Severity: 14, State: 38.
This was a bit odd, it was complaining that the FIM Synchronization Service account had no access to the FIMService database. I’d expect the FIM MA Account to be used for this connection…

I checked the old database/SQL and I could confirm the FIM Sync service has no access to that database… As I didn’t wanted to start handing out permissions on a wild guess I started googling a bit. I came up with this TechNet thread: TechNet Forum: FIM 2010 Update Rollup 2 Problem which suggests granting the FIM Sync service account the FIM_SynchronizationService role within the FIMService catabase:

Of the FIM MA configuration again. Attempt #2:

In words: Unable to update the management agent. The object explorer specified was not found. (Exception from HRESULT: 0x80070776)

Back to google gave me this thread: Technet Forum: Strange stopped-extension-dll-file-not-found error where Craig suggest rebooting the FIM server. I rebooted the server, undid the SQL changes. And tada! It seems all the Synchronization Service needed was a good old restarted. Perhaps restarting the sync service was good enough but I rebooted it anyhow.

Conclusion

I was having troubles reconfiguring the FIM MA and I was able to resolve it by just rebooting the sync server. Configuration changes on SQL were not required.

Recently I did an upgrade of FIM 2010 to MIM2016 for a customer of mine. I’ve described that process here. We’ve only upgraded our lab environment and are now testing whether everything works as expected. Today I was testing the flow that is triggered by adding a new user to the HR source. One of the things that MIM is supposed to do is create an AD account and an Exchange mailbox. However when the export run profile was executed on the AD MA we saw the following error:

Status: no-start-ma

In the Application event log:

In words: The management agent controller encountered an unexpected error.
 
"ERR_: MMS(8228): ..\libutils.cpp(10186): Failed to start run because of undiagnosed MA error
Forefront Identity Manager 4.3.1935.0"

When troubleshooting an issue like this it’s important to narrow down the possible causes. Is there a connectivity issue with AD? Is there an issue with a rules extension? Is there an issue with the Exchange Provisioning component? The latter is quite easy to check. On the configure extensions we can simply set the Provision for to No Provisioning.

After disabling Exchange provisioning the MA seemed to be able to export just fine. So something was up with the Exchange provisioning. To be sure nothing was wrong with the remote PowerShell I tested the URL by opening a remote PowerShell connection to Exchange [technet]. That seemed to go fine. After looking some more in the Application event log I also noticed several Application Crash (event 1000) events whenever I was trying to run an export profile. The application was mmsscrpt.exe. I’m guessing that’s the utility being used to setup the remote PowerShell session and call the Update-Recipient cmdlet.

I found an older article (link) stating errors like this might occur whenever .NET 4.0 is missing. But in my case I was running on a Server 2012 R2 with .NET 4.5.2 installed on it. Either way, that article pushed me into suspecting .NET. We had installed .NET 4.5.2 using the Add-WindowsFeature cmdlet. This is the exact .NET version we had:

As you can see we were running 4.5.51650 which matches .NET4.5.2 (May 2014 Update) If I may believe: http://deletionpedia.org/en/List_of_.NET_Framework_versions I binged a bit to find out whether there were any updates available for .NET 4.5.2 but I couldn’t find any. Then a colleague of mine (Thanks Kevin!) reminded me that very recently .NET 4.6 became RTM. So I went ahead and downloaded it from here:

• All links: https://support.microsoft.com/en-us/kb/3045560
• Offline installer: http://www.microsoft.com/en-us/download/confirmation.aspx?id=48137

After installing the 4.6 package the .NET version showed us 4.6.00081 in the registry. After a reboot I performed the test again and now I could export to AD again while provisioning mailboxes on Exchange!

Conclusion:

Whenever you are preparing a Server 2012 R2 to host the FIM Synchronization Service, do not forget to download and install .NET 4.6 as the .NET 4.5.2 that comes out of the box is not sufficient.