pipeline for Add-FGTFirewallAddressGroupMember returns 500

[poundy]

I'm at last able to start focussing on FGT again for a while and started digging in to the new capabilities in the 0.4.1 release, but I hit a snag.

Based on the help info, it seems Add-FGTFirewallAddressGroupMember will take pipeline input, so you should be able to Get-FGTFirewallAddressGroup | Add-FGTFirewallAddressGroupMember successfully. I've tried using this combo, and it didn't seem to work and I can't be sure whether it's my understanding, my group/member/firewall, or if it's a bug. What I can however do is use the assignment-then-add-member approach that the help info shows, with the same group and member, which does work.

Error message is shown below (redacted).

PS > 
Get-FGTFirewallAddressGroup -vdom root -connection $conn[0] -name TestGroupNameHere | Add-FGTFirewallAddressGroupMember -member TestMemberHere -vdom root

WARNING: The FortiGate API sends an error message:
WARNING: Error description (code): Internal Server Error (500)
WARNING: Error details: {
  "http_method":"PUT",
  "revision":"537.0.665.2897040576.1559001134",
  "error":-3,
  "status":"error",
  "http_status":500,
  "vdom":"root",
  "path":"firewall",
  "name":"addrgrp",
  "mkey":"TestGroupNameHere",
  "serial":"",
  "version":"",
  "build":
}
Unable to use FortiGate API
At C:\Program Files\WindowsPowerShell\Modules\powerfgt\0.4.1\Private\RestMethod.ps1:166 
char:13
              throw "Unable to use FortiGate API"
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     CategoryInfo          : OperationStopped: (Unable to use FortiGate API:String) [] 
   , RuntimeException
     FullyQualifiedErrorId : Unable to use FortiGate API

[alagoutte]

Hi,

Yes, when there is a error it is not easy with FortiGate API...

but if you use -connection, you need to use also for Add-FGTFirewallAddressGroupMember

You can use -Verbose for get more verbose...

[poundy]

aaaah, thats it ! I first was tripped up by VDOM and now by connection too.

Don't take this as anything other than navel gazing.... I wonder if this shows that there would be benefit in having "context" items in the return object around each of these items. It somewhat makes sense to me that an address group is only relevant within the context of a particular FW and a VDOM, so if the object carried along those properties with it, it'd make it harder to mis-use the object later.

(you may have noticed the change in title; the 404 error was wrong VDOM :) )

[alagoutte]

there is already a "context" the global connection ;-) (i think it is very specific use case to use multi connection support case...)

[poundy]

hmm, then I am special :)

Maybe I need FortiManager. I have two FGT sites that I "manually" keep in sync. Well what I (used to) do is do everything by script, and paste the changes to both at once to eliminate drift. With PowerFGT that's much reduced now as I just repeat the commands over two connections.... ok, it'll be much reduced once I convert all my scripts to use PowerFGT but... oh and when I can manage VIPGRPs.

[alagoutte]

For VIPGRPS, i think, you can look AddressGroup file and modified for VIPGRP uri

can you create a issue for add vipgrp and it will tag for don't forget for next release (but no idea when i will work on this...)

and for Multi connect, if i found a idea to be more easy when use pipeline, it will be implement...

[alagoutte]

can be close ?