Hey everyone! I'm encountering a peculiar issue with FortiClient that I'm sure some of you might have experienced too. When the FortiClient VPN disconnects, it sometimes leaves the internal DNS configured on the Wi-Fi adapter, which renders my laptop unworkable until a technician physically resets the DNS to automatic.
We're using NinjaOne, and I want to create a script that users can access through the SysTray feature to run these automation fixes. Today, I was testing with the `Set-DnsClientServerAddress`, but I ran into some trouble.
The command I tried was:
`Set-DnsClientServerAddress -InterfaceIndex 14 -ResetServerAddresses`
Although it indicated success, the DNS settings didn't actually change. Did I miss something here? I confirmed the InterfaceIndex was correct. My device runs Windows 11, and the FortiClient version is 7.4.0, but this issue has been around since version 6. Any advice? Thanks!
2 Answers
It seems like the hard-coded `-InterfaceIndex 14` could be your issue; once you try it on another machine, it might fail. Instead, you should get the current adapter index dynamically with `Get-NetAdapter` to ensure you're targeting the right interface. Just curious, how are you checking if the DNS value hasn't changed? Also, it's bizarre for FortiClient to alter the DNS settings like that!
Why is that surprising? Many VPN clients set internal DNS servers to access internal resources, it's actually quite normal.
It sounds like there’s a policy in place that’s enforcing these DNS settings, which overrides your changes locally. I'm not sure it's a PowerShell issue; your commands look fine, but sometimes local overrides can complicate matters.
I get it, you start on one laptop, but your script should definitely check the interface index before deployment to avoid future issues. I think some of the problems could also stem from how rushed you feel; when I tried it on my laptop, everything seemed to work fine.