Mister_Tom's questions

On the Cisco ASA, changes to the running-config are not automatically saved to the startup-config. This is done manually with "write memory" or "copy running-config startup-config" to write the changes to flash storage.

I would like to verify whether configuration changes have been saved rather than blindly saving repetitively (which I currently do). I've searched Google for commands to check whether the running-config changes have been saved to startup-config, and here are two ugly workarounds that I've found:

1. "reload" command
   • Output of "System config has been modified. Save? [Y]es/[N]o:" when config needs to be saved.
   • Output of "Proceed with reload? [confirm]" when config has already been saved. ANSWER NO or similar to avoid needless reboot!!
2. Copy BOTH your running-config AND startup-config to text files.
   • Use a "diff" utility to compare the text files for differences.

I would love to have a quick clean command or procedure to use to verify the configuration has been saved without risking an accidental reboot. Please post if you have suggestions.

I'm trying to get a software switch configuration working on a Fortigate 100D. It appears like devices plugged into the software switch ports can communicate between each-other, but they cannot reach the IP configured for the software switch "interface" of the fortigate on same subnet. Conversely, the fortigate command-line cannot ping or reach the systems plugged into the soft switch.

Please note that the software switch was configured using instructions provided directly by the fortigate documentation and support team. No indication was given in the documentation or by the support personnel that the feature would not work correctly during runtime when enabled. See below for the solution we came up with after over hour of runtime troubleshooting with fortinet support.

The reason for using soft switch feature in this case is to have capwap wifi "interface" on same subnet as some fortigate wired clients.

I was seeking support from the ServerFault expert community to see if some other network engineer had seen this problem and found a solution. After the question was posted, we continued working the issue with Fortinet support and were able to find a solution. I would still consider this a valuable question for ServerFault since the device was not functioning according to directions provided in the FortiGate documentation and Fortinet support team.

We're having a strange issue with Symantec Endpoint Protection (SEP) version 12.1 on Windows 7 clients.

When our users try to map a new network printer from our print server (double-click on the printer name when browsing \OurPrintServer ) - the standard driver install process begins as usual but ends with the error message: "Windows cannot connect to the printer. Access is denied."

We have tested on multiple systems with different printer shares using different drivers and even different printer manufacturers. The install of all printer drivers not already present on the client system seems to be being blocked by SEP.

A strange thing is that when we disable SEP, the error still occurs and new printer drivers still fail to install. If we completely remove SEP from the client computer, the printer drivers install successfully and the printer shares map as expected.

To further test, we tried other Windows 7 clients on our domain without SEP and they map the printer correctly installing the drivers as expected.

Has anyone seen a problem like this with SEP 12.x on Windows 7 and if so do you have any suggestions on how to resolve the issue? Such a strange case, even when SEP is disabled it is still somehow blocking these printer driver installs. Only when SEP is completely removed do Windows shared network printer driver installs work correctly.

Recently we're having a problem with the "Connection-specific DNS Suffix" automatically changing to an invalid domain on our network.

When a system plugs into the network, our DHCP server gives it the correct domain name suffix using option 15 (DNS Domain Name) = our-domain.com ... this can be verified immediately after getting an ip with ipconfig /all:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix : our-domain.com

After several minutes, some automatic discovery process finds a new (wrong) connection-specific dns suffix and updates the ip configuration with the new information. After this update with the wrong information, ipconfig /all changes to show:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix : novalocal

When this "novalocal" domain is discovered, many of my clients begin having name lookup problems.

This is happening to Windows 7 clients, and I've verified that the issue occurs with or without Bonjour installed. I haven't tried disabling SSDP or UPnP services yet. It is happening on clients with either Symantec firewall or Windows firewall turned on.

I did check for rogue DHCP servers, and offers / leases are only coming from my authorized DHCP servers (no rogues seen or sending offers on the network).

Has anyone seen anything like this before? Any suggestions on how I can find where this "novalocal" is coming from and how to prevent my clients from having their DNS suffix settings changed by some automatic discovery?