Windows Server 2012 stuck in boot loop – remove pending patches in bulk

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: “dism /image:e:\ /get-packages /scratchdir:e:\temp /format:table >> e:\temp\packages.txt” From the command line run “notepad.exe” to launch a GUI to make editing easier then use file > open to locate and open “e:\temp\packages.txt”  The output into the text file will look something similar to: Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.2007.1.8            | Installed | Security Update | 1/31/2018 8:19 PM Package_for_KB4049065~31bf3856ad364e35~amd64~~10.0.1.3                    | Staged | Update  | 1/6/2018 2:17 AM … All that we need from this document is to remove any line that is not showing “Installed”  Once the only lines that remain...

Unable to remove FortiManager from a FortiGate

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 In the CLI if we attempted to remove the FMG IP address we received the following error: Please unregister-device from FortiManager first. The resolution was to change the FMG IP address to 0.0.0.0 and exit the Central Management config.  Then after re-entering the Central Management section again the FMG IP could be removed. Fortigate # config system central-management Fortigate (central-management) # unset fmg FortiGate (central-management) # end Please unregister-device from FortiManager first. object set operator error, -582 discard the setting Command fail. Return code -582 Fortigate # FortiGate # config system central-management FortiGate (central-management) # set fmg 0.0.0.0 Fortigate (central-management) # end Fortigate # Fortigate # config system central-management Fortigate (central-management) # unset fmg Fortigate (central-management) # end Fortigate #...

Outlook clients not authenticating, but OWA and ActiveSync work fine

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 Information: Failure Reason: An Error occured during Logon. Status: 0x80090302 Sub Status: 0xC0000418 We discovered that NTLM had been disabled on the domain controller.  To resolve, check the domain policy, domain controller policy or local policy on the DC and go to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies ->Security Options and check the following two settings: Network security: Restrict NTLM: Incoming NTLM traffic Network security: Restrict NTLM: NTLM authentication in this domain After a gpupdate on the DC, Outlook clients were then able to successfully connect to...

CCAPI: Internal Error (Software Error)

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=1.1.180.1.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. dial-peer voice 100 voip description Dial-peer for Exchange VM destination-pattern 60. session protocol sipv2 session target ipv4:10.5.99.11:5065 session transport tcp dtmf-relay rtp-nte audio incoming level-adjustment -5 audio outgoing level-adjustment -15 codec g711ulaw no vad Other things to check would be codec changes or TCP/UDP changes as either would cause transcoding. Update:  I ran into a similar error again.  This time deleting the dial-peer and re-adding it, along with restarting the SIP services, fixed the...

Exchange Transport rule based on the recipient — which is a group

For Exchange Server, a transport rule can apply actions to messages based on the recipient address.  If you however attempt to use a Distribution List (group) the rule will not save, giving you the following error message:   SentTo predicate does not allow distribution groups. ‘My Group’.     The workaround to this is to instead chose “The Message -> To box contains this person” and then select your group and it should now let you save.  ...