Windows 2008 R2 Password Notification causes more issues than helps

With Windows 7 / 2008 R2 Microsoft changed the way password notifications look. 

After upgrading from PS 4.5 to XenApp 6.5 we fairly quickly found that the default password expiration notification changes from 14 days down to only 5 days.  This doesn't work well in an environment where part time workers may be off a week at a time.  No problem, set the GPO and mark it for 14 days right...  One would think.

Unfortunately, MS changed the popup.

This presents 2 issues in my environment:

• The popup doesn't display for long enough  (this can be corrected via GPO)
• Users tend to miss it
• Or ignore it
• CTRL+ALT+END doesn't work for our Citrix sessions. 
• When connected through the web interface it just doesn't do anything
• When connected from a thin client (Wyse and HP clients) it disconnects the session  ACK!

In our case when connecting from:

• Thin Client - CTRL+ALT+DEL works fine...
• Web Interface - CTRL+F1 works

After messing around with several options I ended up opting for the following:
http://serverfault.com/questions/140816/with-no-password-expire-notification-at-logon-in-windows-7-how-are-you-configur

With a slight amount of modification to the message you can make it fit your scenario.
I then added it to GPO as a user configuration logon script.  With this I added the GPO Loopback mode as "Merge" and applied the policy to the machines that needed it (Citrix, RDS / Terminal Services, others)

Dim oDomain Dim oUser Dim maxPwdAge Dim numDays Dim warningDays warningDays = 300 Set LoginInfo = CreateObject("ADSystemInfo") Set objUser = GetObject("LDAP://" & LoginInfo.UserName & "") strDomainDN = UCase(LoginInfo.DomainDNSName) strUserDN = LoginInfo.UserName Set oDomain = GetObject("LDAP://" & strDomainDN) Set maxPwdAge = oDomain.Get("maxPwdAge") '======================================== ' Calculate the number of days that are ' held in this value. This is line 20 '======================================== numDays = CCur((maxPwdAge.HighPart * 2 ^ 32) + _ maxPwdAge.LowPart) / CCur(-864000000000) 'WScript.Echo "Maximum Password Age: " & numDays '======================================== ' Determine the last time that the user ' changed his or her password. '======================================== Set oUser = GetObject("LDAP://" & strUserDN) '======================================== ' Add the number of days to the last time ' the password was set. '======================================== whenPasswordExpires = DateAdd("d", numDays, oUser.PasswordLastChanged) fromDate = Date daysLeft = DateDiff("d",fromDate,whenPasswordExpires) 'WScript.Echo "Password Last Changed: " & oUser.PasswordLastChanged if (daysLeft < warningDays) and (daysLeft > -1) then Msgbox "Your password expires in " & daysLeft & " day(s)" & chr(13) & "Date Expires: " & whenPasswordExpires & chr(13) & chr(13) & "Press CTRL-ALT-DEL and select the 'Change a password' option" & chr (13) & chr (13) & "NOTE: For PPH Citrix Website:" & chr (13) & "If you logged in through the PPH Citrix Website then please press CTRL+F1 and select the 'Change a password' option", 0, "PASSWORD EXPIRATION WARNING!" End if '======================================== ' Clean up. '======================================== Set oUser = Nothing Set maxPwdAge = Nothing Set oDomain = Nothing


Who would have thought that something as simple as "changing your password" would be such a

nuisance and so poorly implemented by Microsoft.

Fixing the Outlook Address Cache / Autofill after recreating email address in Exchange

Recently I had a scenario where we wanted to convert a distribution group to a user mailbox. This was an email address that everyone uses. Of course this can't be done without deleting the dist group and creating as a user mailbox. Unfortunately when you delete the distribution group and recreate as a user the Outlook autocomplete / autofill will break because the value that outlook looks at is different for the new object.

This will result in a NDR like the following: (for dist group test@mydomain.org)

Delivery has failed to these recipients or groups:

'Test' <mailto:IMCEAEX-_O%3DHERE_OU%3DEXCHANGE%2B20ADMINISTRATIVE%2B20GROUP%2B20%2B28FYDIBOHF23SPDLT%2B29_CN%3DRECIPIENTS_CN%3DTesta56@mydomain.com>

The e-mail address you entered couldn't be found. Please check the recipient's e-mail address and try to resend the message. If the problem continues, please contact your helpdesk.

Diagnostic information for administrators:

Generating server: Server.mydomain.com
IMCEAEX-_O=HERE_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=Testa56@mydomain.com
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##



As Ben points out this can easily be fixed: https://www.simple-talk.com/sysadmin/exchange/exchange-e-mail-addresses-and-the-outlook-address-cache/

This helps keep our 200+ users from having to fix on their own or more likely calling the help desk to have us fix it


And to help convert the IMCEAEX string
http://support.microsoft.com/kb/2807779

\Windows\System32\config\system Status: 0xc000014c missing, or corrupt

On a Lenovo E520 running Windows 7 x64 user ran out of power and system crashed.  When it came back up the user was presented with:
File: \Windows\system32\config\system
Status: 0xc000014c
Info: Windows failed to load because the system registry file is missing, or corrupt.

I tried using the Lenovo recovery media without success.

I then plugged in a Dell recovery disc and just went into the Windows recovery cmd prompt.  At that point I found that the hard disk was mapped to the D drive.

sfc /scannow /offbootdir=d:\ /offwindir=d:\windows


After it finished running I rebooted the computer and gave back to the user (after tucking away my handy Dell disc)

IIS7 - Cannot find the certificate request that is associated with this certificate file

Seems like once a year (or longer) when I renew our SSL cert this causes me some headache.  The worst part about the error is that it's false and the cert was created just fine!

In this case I create the CSR and get the new cert which is delivered in PKCS #7 (.p7b).  When you "complete Certificate Request" and point it to the p7b file (note you have to change it to *.*) you then get the error "Cannot find the certificate request that is associated with this certificate file".

At that point I usually troubleshoot if I created the p7b incorrectly (which I did nothing wrong).


Instead you just need to click OK and then hit refresh (F5) on the IIS7 certificates screen.  Your new cert appears :)

At this point you can export it as pfx and convert to pem if needed.