The following post was submitted by Jon Worley in response to a server stuck in a boot loop due to pending updates failing to install:
This is a summary of what I did to avoid manually removing 28 different packages using the long form name of them without access to Powershell in the Windows RE. This worked better than using DISM to revert pending actions or deleting “pending.xml” but takes a little additional prep work before running the script.
- Boot into the Windows RE from an ISO and launch into the command prompt recovery mode.
- Determine which drive has the image as it can vary by using “dir c:\, dir d:\, etc” until you find the system drive, in this case it was mounted to e:\
- If it doesn’t exist create a temp directory with “mkdir e:\temp”
- See if there are staged packages causing the hang up with:
“dism /image:e:\ /get-packages /scratchdir:e:\temp /format:table | more”
- If there are staged packages output them into a text file for easier manipulation with: read more…
In order to resolve a failed relationship between a FortiGate and FortiManager we needed to remove the FortiGate. In FortiManager this worked fine, however in FortiGate the relationship still persisted (under Security Fabric -> Settings -> Central Management).
If we attempted to disable the Central Management toggle we received the following error:
Failed to save FortiManager settings
We had an issue where a clients’ Outlook connectivity stopped working and they were continuously prompted for credentials. Mysteriously OWA and ActiveSync were fine. In the Security logs on the Exchange server we saw a lot of the following:
Source: Microsoft Windows security auditing.
Event ID: 4625
Failure Reason: An Error occured during Logon.
Sub Status: 0xC0000418 read more…
We changed a customer from PRI to SIP trunk and after the change, the Exchange UM stopped working for calls coming in from the outside. We found the following error in the logs:
%VOICE_IEC-3-GW: CCAPI: Internal Error (Software Error): IEC=184.108.40.206.13.112 on callID 78
Some posts mentioned upgrading the firmware (which we did with no effect). The dial-peer pointed to Exchange had some volume adjustments on it. Once we removed the adjustments, the error went away and calls went through. read more…
On the pre 4000 series ISRs you would use the regular Cisco escape sequence to exit a service module — CTRL-SHIFT-6 followed by X. In the 44xx and 43xx series routers the switch modules do not respond to the regular escape sequence from the console. Instead, to escape back to the router console use — CTRL-A followed by CTRL-Q.