Thursday, January 29, 2015

Failed to Add Update Source for WUAgent of type 2 (Error = 0x80004005)

I ran across an issue this morning where Windows Updates were not getting deployed to a client. I checked the reports, and found that the client was not reporting any missing updates.
I knew this client was not working, as the compliance state was listed as unknown on the SCCM reports. The first thing I check was policy. I was unable to get to the policy editor and that seems tol point to something in this direction.
The execmgr.log was also clean.
Next, I checked the WUAHandler.log and true enough the error is in here

<![LOG[Failed to Add Update Source for WUAgent of type (2) and id ({CEF9E8E9-C241-47CC-B86A-A7380539BF47}). Error = 0x80004005

To resolve issue, delete the C:\Windows\System32\GroupPolicy folder and restart the SCCM Agent.
After which you should see entries similar to the below

<![LOG[Enabling WUA Managed server policy to use server: https://SINWSUS01.intlsos.com:8531]LOG]!><time="11:51:44.524+000" date="01-29-2015" component="WUAHandler" context="" type="1" thread="4228" file="sourcemanager.cpp:1054">
<![LOG[Waiting for 2 mins for Group Policy to notify of WUA policy change...]LOG]!><time="11:51:44.540+000" date="01-29-2015" component="WUAHandler" context="" type="1" thread="4228" file="sourcemanager.cpp:1060">
<![LOG[Waiting for 30 secs for policy to take effect on WU Agent.]LOG]!><time="11:52:05.792+000" date="01-29-2015" component="WUAHandler" context="" type="1" thread="4228" file="sourcemanager.cpp:1124">
<![LOG[Added Update Source ({CEF9E8E9-C241-47CC-B86A-A7380539BF47}) of content type: 2]LOG]!><time="11:52:35.827+000" date="01-29-2015" component="WUAHandler" context="" type="1" thread="4228" file="sourcemanager.cpp:1381">
<![LOG[Async searching of updates using WUAgent started.]LOG]!><time="11:52:35.936+000" date="01-29-2015" component="WUAHandler" context="" type="1" thread="4228" file="cwuahandler.cpp:587">

Monday, January 26, 2015

Backdoor to SQL Database


On a Monday when I am suffering from a sever bout of Garfield's Syndrome, I delete my own admin account which has been assigned sysadmin access to my SQL databases for my reporting server.

Shit! Does it mean I cannot access to the databases any more.
Then i thought of a backdoor method to access the database using the system account.

In order to do this, you will need to have a copy of the psexec which can be downloaded from here. Place this on the server and then in a command prompt execute this command:psexec -i -s SSMS.exe.

Once you are in, you will be able to very much do whatever you like :)

Tuesday, November 18, 2014

Missing mailbox / Distribution list in Offline Address Book

You might experience this error during an Offline Address Book generation cycle:

Index : 94460
EntryType : Warning
EventID : 9327
Message : OALGen skipped some entries in the offline address list ‘\Global Address List’. To see which entries are affected, event logging for the OAL Generator must be set to at least medium.
- Default Offline Address List
Category : OAL Generator
CategoryNumber : 13
ReplacementStrings : {\Global Address List, Default Offline Address List}
Source : MSExchangeSA

After you set the event log level for the OAL Generator to at least medium, eg. by using this EMS command:
Set-EventLogLevel ‘MSExchangeSA\OAL Generator’ -level Medium
You start seeing these errors:

Index : 94454
EntryType : Error
EventID : 9325
Message : OALGen will skip user entry ‘user1′ in address list ‘\Global Address List’ because the SMTP address ” is invalid.
- Default Offline Address List
Category : OAL Generator
CategoryNumber : 13
ReplacementStrings : {user1, \Global Address List, , Default Offline Address List}
Source : MSExchangeSA

As we can see from the error in the Event Log, OAL Generator claims that the SMTP address ” (blank) is invalid. This is not surprising, as a blank address can not be used for anything.
I have discovered one reason for this error, there might be more. If the user’s primary SMTP address does not match the value in the mail attribute in Active Directory, this error is generated. This happens if you change the primary SMTP address in EMC. EMC does not update the address in the mail attribute. To see if you have any recipients in your organization that have a mismatch between these two values, run these EMS commands:

get-mailbox -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto

get-distributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto

get-dynamicdistributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto

This should be possible to do with Get-Recipient as well, but I cannot make it work. Get-Recipient always return every recipient in the organization.

To remedy this situation, these EMS commands may be of interest:

get-mailbox -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-Mailbox $_ -WindowsEmailAddress $_.PrimarySMTPAddress }

get-distributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-distributiongroup $_ -WindowsEmailAddress $_.PrimarySMTPAddress}

get-dynamicdistributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-dynamicdistributiongroup $_ -WindowsEmailAddress $_.PrimarySMTPAddress}

You should probably test these commands with the –whatif parameter added to the Set cmdlets.
A good pointer as to which recipients have a mismatch between these values, are those recipients who no longer have their Email addresses updated by a recipient policy. You can quickly list which recipients are in this state:

get-mailbox -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto

get-distributiongroup -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto

get-dynamicdistributiongroup -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto

Also recipients who are targets of E-Mail address policies (EAP), but where those policies have not been applied, are candidates for this error.

Lastly, you cannot set the mail attribute if a recipient is a target of an EAP.
Remember to set the Event Log level back to it’s original value after you have finished troubleshooting:

Set-EventLogLevel ‘MSExchangeSA\OAL Generator’ -level lowest