Showing results for 
Search instead for 
Did you mean: 

vSZ - command "set scg ip" not allowed in AP script

New Contributor II
Hi all,
we need to change IP address of our vSZ-H, which is hosted on our own public cloud infrastructure.

Though we are pretty confident that we did it well in the past, declaring FQDN instead of IP address in "set scg ip" command, we want to make sure that all of our APs are correctly configured before going live with new IP address.

APs are distributed over many customers, thus DHCP 43 is not an option.

We would like to push an AP script command, as suggested in the following KB article:

Also, as per this article, "any AP CLI command will be accepted" into the AP script.

However, when we upload the script, we get the following error: "command[set scg ip] is not allowed in AP CLI Script file."

Script is very simple, as following:
#define AP FW version
fw_version= #define Model class model=all # Command set scg ip FQDN
Any clue on how to upgrade scg ip remotely (with no easy SSH access)?

Valued Contributor
Hi Marco,

As far as I know that has not been changed.
Please raise a case via the support portal to have a support engineer look at it.


Contributor II
Starting from SZ OS, the following commands are excluded in the AP CLI Script feature in order to protect the integrity and stability of the system.

AP CLI Command Blacklist
  • reboot
  • set factory
  • set scg reset
  • set scg init
  • set scg ip
  • set scg disable/enable
  • set hub disable/enable
  • set interface
  • set password
  • set login
As Martin suggested above, please contact support desk who can advise you the best way moving forward.


Esteemed Contributor II
Try using a real FQDN (!)  

New Contributor II

While not pretty, you could in theory do this from the CLI of the SZ.  Something like the following should work.

remote ap-cli "set scg ip IP/FQDN"
remote ap-cli "set scg ip IP/FQDN"

There's a bit of a delay between inputting one command and a return of "OK", so using something like AutoHotkey to add your own delay in automating this could help you accomplish what you're trying to do.

Likewise you could change the set to get and verify they are all configured as you desire.  The delay between the response(s) will be the pain point I imagine.