Force KCC (Knowledge Consistency Checker) to run on a domain controller

Sometimes after demoting domain controllers you may be left with inconsistent NTDS connection objects in Active directory. In my case there was an NTDS connection object listed under one of the domain controllers at our central site which referenced a recently demoted domain controller at a remote site. I needed an NTDS connection object pointing pointing to the newly installed DC at the remote site instead. To fix this i simply deleted the incorrect NTDS connection object in the ‘Sites and Services’ console, from the central site domain controller, and then forced KCC to run on the same domain controller by running:

repadmin /kcc

This forces the domain controller that you run the command on to check its inbound replication topology immediately and generate any missing connections. After running this command a new NTDS connection object was generated from the new DC at the remote site. This can either be verified by checking under the Domain Controllers NTDS Settings, in the ‘Sites and Services’ Console or by running:

repadmin /showrepl

Upgrading the ASA and ADSM software on a Cisco ASA series firewall

Firstly telnet or ssh in to your ASA device, in this example I am using an ASA 5505 with a security plus license installed.

telnet 192.168.0.1

Type in your telnet password. At the prompt type:

enable

At this stage you can use the show version command to show the current running ASA software version. The show bootvar command will also show you which software image file the device is using. Next type:

show disk0:

This will show you the current contents of your flash memory and also the amount of free space. It is important that you check that there is enough free space in flash memory to accomodate the new image files that you want to upload before doing so. In this example the current running versions were:

asa821-k8.bin

asdm-621.bin

I also noticed a couple of other software images taking up space in the flash memory which were asa831-k8.bin and asdm-631.bin. Knowing that these were not currently in use, and that I would be upgrading to a more recent version I decided to delete these to free up space by issuing the following commands:

delete asa831-k8.bin

delete asdm-631.bin

Having downloaded asa842.bin and asdm645-206.bin from cisco.com, I next copied these the the flash memory on the ASA, as shown in the prompts and commands below:

copy tftp disk0:

address or name of remote host [192.168.0.10]?   Press ‘Return’ to confirm or enter a different ip address for an alternative tftp server

source filename [asa821-k8.bin]? asa842-k8.bin

destination filename [asa842-k8.bin]? Press return to confirm the destination filename

Ths ASA software image will copy from the tftp server to flash memory.

copy tftp disk0:

address or name of remote host [192.168.0.10]?   Press ‘Return’ to confirm or enter a different ip address for an alternative tftp server

source filename [asa821-k8.bin]? asdm-645-206.bin

destination filename [asdm-645-206.bin]? Press return to confirm the destination filename

The ASDM software image will copy from the tftp server to flash memory.

Enter configuration mode:

conf t

Next set the new ASA software image to be the boot image using the following command:

boot system disk0:/asa842-k8.bin

Then set the new ASDM software image to be the preferred ASDM image:

asdm image disk0:/asdm-645-206.bin

Issuing the following commands to save these settings:

exit

write mem

and then the following command to restart the ASA device:

reload

At this stage you should be done although in this example I came up against another issue that I will explain for completeness. After rebooting the ASA the device came up fine but on trying to access ASDM, after logging in the status bar would hang on 15% with a status of ‘Discovering Device Information’. I was unable to access ASDM. Notes on cisco.com explained that after the software upgrade is completed the system will upgrade the configuration on the following boot. When upgrading from 8.2.1 to 8.4.2 the subsequent configuration upgrade caused an error log to be written to flash in the format:

upgrade_startup_errors_datetime.log

These error logs can be viewed by issuing the command:

show startup-config errors

In this case the content of these log files was:

INFO: MIGRATION – Saving the startup errors to file ‘flash:upgrade_startup_errors_201112201404.log’ Reading from flash… ! REAL IP MIGRATION: WARNING In this version access-lists used in ‘access-group’, ‘class-map’, ‘dynamic-filter classify-list’, ‘aaa match’ will be migrated from using IP address/ports as seen on interface, to their real values. If an access-list used by these features is shared with per-user ACL then the original access-list has to be recreated. INFO: Note that identical IP addresses or overlapping IP ranges on different interfaces are not detectable by automated Real IP migration. If your deployment contains such scenarios, please verify your migrated configuration is appropriate for those overlapping addresses/ranges. Please also refer to the ASA 8.3 migration guide for a complete explanation of the automated migration process.

INFO: MIGRATION – Saving the startup configuration to file

INFO: MIGRATION – Startup configuration saved to file ‘flash:8_2_1_0_startup_cfg.sav’ *** Output from config line 4, “ASA Version 8.2(1) ” NAT migration logs: INFO: NAT migration completed. Real IP migration logs:  No

In order to complete the configuration upgrade it was necessary to save the config to memory as stated here:

write mem

After restarting the ASA device a second time ASDM was accessible, and the upgrade was complete.

References:

Cisco ASA 5500 Migration to Version 8.3 and Later

Release Notes for the Cisco ASA 5500 Series, 8.4(x)

PIX/ASA: Upgrade a Software Image using ASDM or CLI Configuration Example