No parameter defined in the script or function for the input binding 'Timer'.Stack:

[rlittler]

Azure function V3 does not support this function, downgrade to V1:

The instructions for downgrading your Azure function is as follows:

1. Login to Portal
2. Find Function App
3. Navigate to configuration
4. Change FUNCTION_EXTENSIONS_VERSION from ~3 to ~1

[ScottMonolith]

@myhomenwlab and @rlittler - not sure if you still use this function app, but I did find how to make it work with (now v4) function apps.

I will write a PR once I'm all done, but for now here is the fix - just add 'param($Timer)' to the run.ps1 script. I placed it at line 44.

Appreciate your PR @myhomenwlab, it definitely helped me along. Still having some issues but at least I was able to get the function app to run successfully.

Edit - I spoke too soon. I now have additional issues, I believe related to the AzureRM cmdlets being deprecated. Going to switch to the Az cmdlets and see if that resolves the issues.

Edit 2 - was able to get everything working except the mail alert. I can't get the Resolve-DnsName cmdlet to work, which is part of the DnsClient module that should be included with Windows machines. Minor issue, having the function app make the route table change is the main thing.

[expoearchie]

@myhomenwlab and @rlittler - not sure if you still use this function app, but I did find how to make it work with (now v4) function apps.

I will write a PR once I'm all done, but for now here is the fix - just add 'param($Timer)' to the run.ps1 script. I placed it at line 44.

Appreciate your PR @myhomenwlab, it definitely helped me along. Still having some issues but at least I was able to get the function app to run successfully.

Edit - I spoke too soon. I now have additional issues, I believe related to the AzureRM cmdlets being deprecated. Going to switch to the Az cmdlets and see if that resolves the issues.

Edit 2 - was able to get everything working except the mail alert. I can't get the Resolve-DnsName cmdlet to work, which is part of the DnsClient module that should be included with Windows machines. Minor issue, having the function app make the route table change is the main thing.

Hi Scott, would you be able to share the script you got working? I have an updated version with the Az cmdlets but even though I've modified the requirements.psd1 file it still complains it doesn't understand the 'Connect-AzAccount' and 'Get-AzVM' cmdlets.

I also thought of a couple of additional modifications I can make:

• Using SendGrid to send emails rather than the deprecated Send-MailMessage
• Changing the Logic of the failovers to match the logic of WAN failovers in Meraki MX SD-WAN. If vMX 1 is down, it'll failover to vMX 2. If vMX1 comes back up the Meraki WAN will send everything back to vMX 1 but the script won't until vMX 2 is down and vMX 1 is up.

[ScottMonolith]

Hi Scott, would you be able to share the script you got working? I have an updated version with the Az cmdlets but even though I've modified the requirements.psd1 file it still complains it doesn't understand the 'Connect-AzAccount' and 'Get-AzVM' cmdlets.

I also thought of a couple of additional modifications I can make:

* Using SendGrid to send emails rather than the deprecated Send-MailMessage

* Changing the Logic of the failovers to match the logic of WAN failovers in Meraki MX SD-WAN. If vMX 1 is down, it'll failover to vMX 2. If vMX1 comes back up the Meraki WAN will send everything back to vMX 1 but the script won't until vMX 2 is down and vMX 1 is up.

Hi Archie,

Yes, I apologize on the delay - I will get a PR in soon. Using SendGrid is a good idea, and that's interesting about the Meraki failover - I kind of had that suspicion but do not have access to the Meraki dashboard (we have a MSP handle that unfortunately).

I'd also like to add a more robust failover, using the VM status is not ideal - do you have any ideas on that? The folks who manage the Meraki said there's no TCP port status to monitor and the VM status is the 'only' way.

Edit - please see PR 13

[expoearchie]

Thank you very much for sharing your amends on this script. With your script I still get the Timer parameter error unless I set the Azure function version to version 1. I also get errors with the new Az powershell modules

Set-AzContext : The term 'Set-AzContext' is not recognized as the name of a cmdlet, function, script file, or operable program.

[expoearchie]

To answer your question, we have found monitoring a Meraki vMX on it's public IP address on TCP/80 to be the best way to monitor the appliance is up and running.

If you're interested take a look at the latest version of my script here (I've also updated the README with modern screenshots and instructions:
https://github.com/expoearchie/azurefunction-nva-udr-failover

[ScottMonolith]

Thank you very much for sharing your amends on this script. With your script I still get the Timer parameter error unless I set the Azure function version to version 1. I also get errors with the new Az powershell modules

Set-AzContext : The term 'Set-AzContext' is not recognized as the name of a cmdlet, function, script file, or operable program.

Huh, that is odd... perhaps the deployment of the function app is different - I used VSCode to deploy the function app, which added some additional files that are not in my PR.

The Timer parameter error should definitely go away if you add that $Timer param to the top of the script:

https://github.com/Azure/ha-nva-fo/pull/13/files#diff-44020245dd84064ca42e9a070c5607395544d7f4025387a9dc5ccfdb09744402R46

The requirements.psd1 should take care of the Az cmdlets as well. You've set the function app to runtime v4? I honestly had a lot of problems with the deployment of the function app, that was new to me - using VSCode really helped with getting that deployed. I'll make another branch on my repo and commit all of those changes, maybe that will help you.

To answer your question, we have found monitoring a Meraki vMX on it's public IP address on TCP/80 to be the best way to monitor the appliance is up and running.

If you're interested take a look at the latest version of my script here (I've also updated the README with modern screenshots and instructions:
https://github.com/expoearchie/azurefunction-nva-udr-failover

I will take a peek, thanks for the suggestion!

Edit - seems port 80 is not exposed on the public IP... it is listening on the private IP. There's no NSG associated with the vMX appliance, so not sure why that isn't exposed on the public IP.

[sneakyrussian]

To answer your question, we have found monitoring a Meraki vMX on it's public IP address on TCP/80 to be the best way to monitor the appliance is up and running.

If you're interested take a look at the latest version of my script here (I've also updated the README with modern screenshots and instructions: https://github.com/expoearchie/azurefunction-nva-udr-failover

Hi @expoearchie,

Tried the function app with your code (thanks for sharing!) and "MyTimerTrigger" is getting errors with following messages:

2023-08-15 18:39:29.999
Executing 'Functions.MyTimerTrigger' (Reason='Timer fired at 2023-08-15T18:39:29.9988701+00:00', Id=5c9f262a-8db1-4faa-932c-26c1ba3f592d)
Information

2023-08-15 18:39:30.079
Result: Failure Exception: No parameter defined in the script or function for the input binding 'myTimer'. No input binding defined for the parameter 'Timer' that is declared in the script or function. Stack: at Microsoft.Azure.Functions.PowerShellWorker.AzFunctionInfo..ctor(RpcFunctionMetadata metadata) in /mnt/vss/_work/1/s/src/FunctionInfo.cs:line 134 at Microsoft.Azure.Functions.PowerShellWorker.FunctionLoader.LoadFunction(FunctionLoadRequest request) in /mnt/vss/_work/1/s/src/FunctionLoader.cs:line 52 at Microsoft.Azure.Functions.PowerShellWorker.RequestProcessor.ProcessFunctionLoadRequest(StreamingMessage request) in /mnt/vss/_work/1/s/src/RequestProcessor.cs:line 245

Was hoping you could possibly know how to work around this, please?

When testing the code it also returns the following error (together with other similar/related errors):

2023-08-15T20:07:36.095 [Error] Connect-AzAccount : The term 'Connect-AzAccount' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.at run.ps1: line 247+ Connect-AzAccount+ _________________+ CategoryInfo : ObjectNotFound: (Connect-AzAccount:String) [], CommandNotFoundException+ FullyQualifiedErrorId : CommandNotFoundException
2023-08-15T20:07:36.157 [Error] Get-AzVM : The term 'Get-AzVM' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.at run.ps1: line 260+ Get-AzVM+ ________+ CategoryInfo : ObjectNotFound: (Get-AzVM:String) [], CommandNotFoundException+ FullyQualifiedErrorId : CommandNotFoundException

Thanks a lot in advance!

[ScottMonolith]

@sneakyrussian - I was a bit lost on your other post, but there is more detail here - it appears you are missing the Az cmdlets. Do you have the requirements.psd1 file?

[sneakyrussian]

@sneakyrussian - I was a bit lost on your other post, but there is more detail here - it appears you are missing the Az cmdlets. Do you have the requirements.psd1 file?

Hi @ScottMonolith,

Yes, I do and below are its contents. I've now implemented @expoearchie's code but errors were pretty much the same when using your latest "patch-meraki-vmx" code.

requirements.psd1:

This file enables modules to be automatically managed by the Functions service.

See https://aka.ms/functionsmanageddependency for additional information.

@{
# For latest supported version, go to 'https://www.powershellgallery.com/packages/Az'.
# To use the Az module in your function app, please uncomment the line below.
'Az' = '9.'
'Az.Accounts' = '2.'
'Az.Compute' = '5.'
'Az.Network' = '5.'
'Az.Resources' = '6.*'
}

[sneakyrussian]

@ScottMonolith @expoearchie,

Looks like it was failing due to timers function name being "myTimer" and line 44 in run.psd1 was referencing $Timer. Once that's sorted, the function runs fine in one Azure tenant but not in another, where it simply times out and/or throws the same error related to Az commands not being recognized. Any advise would be much appreciated.

[ScottMonolith]

@sneakyrussian - not sure why that would need to be changed, my function app is running fine with $Timer as opposed to $myTimer. However the MS documentation does state $myTimer - and if it works, don't fight it.

As for the Az cmdlets not being recognized, I would compare what you have done with the one Azure tenant vs the other. I'm guessing it's how the function app was deployed, but I am far from an expert on function apps - before this project I had never deployed a function app, and since this project I have not deployed any new ones!

Edit - well this proves how bad I am with function apps. There is a 'function.json' file that specifies the name of the timer. Not sure how I messed this up and it still works, but in my deployed function app the timer is just called 'Timer':

However, the function.json file it is set to 'myTimer'. Apologies for the mixup there, I'll get it corrected on my branch!

Fixed.
ScottMonolith@421d027