I’ve upgraded my desktop to windows 8 lately and since the upgrade I’ve noticed that each time the computer enters sleep mode or hibernation it keeps turning on my itself mysteriously and no apparent reason.
Well…no more!! Here’s the actual line of events that led me to the solution:
Went through some event viewer entries, specifically looking at Power-Troubleshooter and Kerner-General source that did not provide me with anything…
Double checked that no one is touching the mouse or keyboard… 🙂
Made sure that the “Allow wake timers” option is not enabled for the active power scheme
Disabled the “Allow this device to wake up the computer” option on the network card adapter Power Management settings tab – you can query all devices that are allowed using the following command (cmd not PowerShell): powercfg -devicequery wake_armed
Only after being frustrated again from the computer still waking up with no apparent reason I’ve noticed that it keeps waking up at around specific times, which led me to the conclusion that it’s probably a schedule task that was waking the computer up !
Seems like there is a Media Center task names mcupdate_scheduled that was causing all the trouble !
So, I’ve written a small PowerShell script to disable the “wake the computer to run this task” option from all scheduled tasks at once, and that did the trick!
This script should work fine with Windows 8 or Server 2012 and might serve as an example for manipulating scheduled tasks with PowerShell.
I’ve recently had an unusual situation I wanted to share. A client of mine had a geographically stretched Exchange 2010 DAG cluster that crashed really bad, the original “active” servers had been lost beyond repair… luckily the databases were replicated to another location, so the data was saved. In addition the client was in between a migration from Exchange 2007 to Exchange 2010 (the 2007 servers were not effected from the disaster..).
Just for the sake of explaining a little more, the original “active” servers should have been restored with the setup.com /m:recoverserver , but due to the nature of the failure those servers and their names are gone and were no longer required. Those failed Exchange 2010 DAG member servers were completely deleted from Active Directory using ADSIEdit.
To recover the Exchange 2010 environment I’ve done a few steps, following which the Exchange DAG was online and service was restored.
Restored the DAG to the DR site (evict nodes from the cluster, modify the quorum, leverage AlternativeWitnessServer): Restore-DatabaseAvailabilityGroup
Created a new ClientAccessArray in the new AD site
Modified all databases with Set-MailboxDatabase so the new CAS array is now the RpcClientAccessServer
Made sure all databases are active within the our new site and on the correct servers with Move-ActiveMailboxDatabase
Removed the lost database copies on the lost DAG members with Remove-MailboxDatabseCopy
Forcibly removed the lost DAG members from the DAG: Remove-DatabaseAvailabilityGroupServer -ConfigurationOnly
Following the actions above, service was restored, and all was good, until we encountered an issue with users located on the Exchange 2007, they reported that they could not retrieve any free/busy information from other users (which were all located on Exchange 2010 databases).
A quick troubleshooting showed that configuration was fine (URL’s were set correctly, networking access was fine, permissions were okay etc..), so I’ve enabled the troubleshooting log on an outlook client while logged on as an 2007 user. Looking at the xxxx-xxx-AS.log (availability service logs) generated from outlook, I was able to extract the root cause:
<FreeBusyResponse><ResponseMessage ResponseClass="Error"><MessageText>Unable to find a Client Access server that can serve a request for an intraforest mailbox <Jhon Doe>;SMTP:Jhon.Doe@Contoso.com., inner exception: The server MBX2.contoso.com was not found in the topology.</MessageText><ResponseCode>ErrorServiceDiscoveryFailed</ResponseCode><DescriptiveLinkKey>0</DescriptiveLinkKey><MessageXml><ExceptionType xmlns="http://schemas.microsoft.com/exchange/services/2006/errors">Microsoft.Exchange.InfoWorker.Common.Availability.ServiceDiscoveryFailedException</ExceptionType><ExceptionCode xmlns="http://schemas.microsoft.com/exchange/services/2006/errors">5021</ExceptionCode></MessageXml></ResponseMessage><FreeBusyView><FreeBusyViewType xmlns="http://schemas.microsoft.com/exchange/services/2006/types">None</FreeBusyViewType></FreeBusyView></FreeBusyResponse>
The availability service on the Exchange 2007 server was trying to locate the users’ using its msExchHomeServerName value which pointed to a deleted server, one of the original “active” DAG members that was lost ! Looking at the attributes values of John Doe (per my example above) reviles that the values of homeMTA and msExchHomeServerName were pointing to non existing values, the homeMTA clearly shows a deleted server value, and the msExchHomeServerName points to a server that no longer exists. here’s an example of what I saw:
I’ve wrote a small PowerShell script that helps update the values for all affected users using a LDAP filter and the Get-User cmdlet from the Active Directory Module and the Set-Mailbox -ConfigurationOnly cmdlet.
Use this script on your own risk, make sure to always double check your self before running on a production environment.
Make sure you modify the LDAP filter $filter and the MBX2 per your configuration.
The conclusion from this case was very interesting to me, the scenario we had here was a “typical” cross site activation of an Exchange 2010 DAG, but due to the nature of the failure, we were forced to re-home the mailboxes as if we were using Database Portability! (excluding the actual database change of course). See the links below for more about Database Potability.
Shay Levi (MVP) has posted yet another great PowerShell tip,
this time he blogged about how to modify the EmailAddresses property ( which is actually a MultiValuedProperty ) with powershell 2.0 new capabilities, making adding an additional or removing an email address from a recipient a snap!