Site Sections
Posts
24
Comments
229
Trackbacks
0
December 2007 Blog Posts
How to REALLY clean out free/busy data

So, a desktop support guy came over the other day because he was stuck on a problem.

I'm sorry, I mean to say: A desktop admin came over the other day for some assistance in resolving an issue for a customer. That's more professional sounding.

 

The gist of the problem was that the user had her mailbox moved, and afterward could not have things done such as adding or removing delegates or make appointments.

Also, when I tried cleaning the free/busy information, I would get the error "Unable to clean your free/busy information." Notice that it didn't have the word

"local" in the error message. It was quite a strange problem.

So I added the mail profile the user with the issu to my system and then opened my Outlook as her. Same problem! Must be something on the server, something inside the mailbox, some type of corruption to her free/busy entry in her mapi store (her mailbox.)

 

Here is the gist of the fix.

Download MfcMapi and extract it (just double-click on it.)

Go to Session > "Logon and Display Store Table" and choose the profile of the user. (You must have already added the profile for this to work.)

Double click the Instance that starts with “Mailbox -” and has the username you want in the display name.

Expand "Root - Mailbox" (if it isn't already expanded)

Click on IPM_SUBTREE and on the right-hand pane delete PR_FREEBUSY_ENTRYIDS if it's there. (right-click and choose delete.)

Expand IPM_SUBTREE and click on Inbox and again, on the right-hand pane delete PR_FREEBUSY_ENTRYIDS.

Exit out of MAPI Editor.

Run /cleanfreebusy on the mailbox by starting outlook from the command line with the /cleanfreebusy switch.

So if you have outlook 2003 installed in the default location, you would type C:\Program Files\Microsoft Office\OFFICE11\Outlook.exe /cleanfreebusy

When Outlook comes up, make sure you choose the user's profile that has the issue. Otherwise you'll clean out your own free/busy entry.

Close out of Outlook and get back in with your own profile now, because you are done. Oh, and let the user know the problem is fixed.

 

Thanks to J. D. Wade for your blog on this subject: http://wadingthrough.wordpress.com/2006/07/31/unab...

 

Here is a good tutorial on how Exchange handles Free/Busy information: http://www.msexchange.org/tutorials/FreeBusy-Folde...

Learn it, love it.

posted @ Thursday, December 27, 2007 3:49 PM | Feedback (16)
Black Login Screen, or Black Logon Screen

So, I'm not sure if it's a login screen or a logon screen. I know Microsoft has defined the difference between login and logon. I'm too lazy to look it up though.

We ran across an issue the other day and I wanted to share it with all you SysAdmins and SysEngineers out there.

When logging into a certain server, whether using RDP, SMS, VNC, or RiLO, we would get the MSGINA login screen, but there was blackness all around it. I don't have a screenshot, but it looked, well... dark.

I'm guessing the cause was of the issue was a webAdmin (this was a web box) with too few skills. But here's what the technical cause was, and the solution too:

 

Looking at the server's registry, the following key had all it's values set to zero:

HKEY_USERS\.DEFAULT\CONTROL PANEL\COLORS

I exported the key from another server and imported it to the server that had gone GOTH on me.

I didn't feel like bumping my way through the login process so here is what I did:

1. I exported the settings from a known good computer and copied the exported file to the c: drive on the bad computer.

2. I then logged onto the bad computer using this command: psexec \\servername cmd.

3. I then did a quick "cd \" to get me to the root of c:.

4. I then did this: "regedit /s <exportedfile.reg>"

5. Lastly I rebooted.

 

One thing still remains unanswered. How the HECK did those settings get changed?

Oh, if you want to copy the below text and make your own regfile, or if you want to manually set the values, here is the contents of my regfile:

Windows Registry Editor Version 5.00

[HKEY_USERS\.DEFAULT\Control Panel\Colors]
"ActiveBorder"="212 208 200"
"ActiveTitle"="10 36 106"
"AppWorkSpace"="128 128 128"
"Background"="102 111 116"
"ButtonAlternateFace"="181 181 181"
"ButtonDkShadow"="64 64 64"
"ButtonFace"="212 208 200"
"ButtonHilight"="255 255 255"
"ButtonLight"="212 208 200"
"ButtonShadow"="128 128 128"
"ButtonText"="0 0 0"
"GradientActiveTitle"="166 202 240"
"GradientInactiveTitle"="192 192 192"
"GrayText"="128 128 128"
"Hilight"="10 36 106"
"HilightText"="255 255 255"
"HotTrackingColor"="0 0 128"
"InactiveBorder"="212 208 200"
"InactiveTitle"="128 128 128"
"InactiveTitleText"="212 208 200"
"InfoText"="0 0 0"
"InfoWindow"="255 255 225"
"Menu"="212 208 200"
"MenuText"="0 0 0"
"Scrollbar"="212 208 200"
"TitleText"="255 255 255"
"Window"="255 255 255"
"WindowFrame"="0 0 0"
"WindowText"="0 0 0"

posted @ Thursday, December 27, 2007 3:03 PM | Feedback (3)
Checking If an AD attribute is NOT set.

OK, I just wanted to post this really quick for all of you vbscripters out there.

I was doing the following LDAP Search in my vbscript:

objCommand.CommandText = "<LDAP://" & strDomainNCDN & ">(&(sAMAccountName=" & strUserName & "));sAMAccountName,employeeID;subtree"

strDomainNCDN is just the Domain Naming Context Distinguished Name. That's what I call it anyway. It's actuall just the Distinguished Name of the Domain, but I get it by querying for the default naming context of whichever domain I'm working in like this:

Set objConnection = CreateObject("ADODB.Connection")
objConnection.Open "Provider=ADsDSOObject;"
Set objCommand = CreateObject("ADODB.Command")
Set objCommand.ActiveConnection = objConnection
objCommand.Properties("Page Size") = 500
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
Set objRootDSE = getObject("LDAP://rootDSE")
strDomainNCDN = objRootDSE.GET("DefaultNamingContext")
set objDomain = GetObject("LDAP://" & strDomainNCDN)

This keeps my scripts nice and Portable, which to me means there is no need to change the script to have it work in another environment.

So, back to my example above in bold. If I wanted to see if the employeeID is null I would do the following against the returned recordset:

If IsNull(objRecordset.Fields(1).Value) Then

   Do whatever

End If

 

So the key to checking for a null value in a recordset of Active Directory attributes returned from an LDAP query inside your vbscript is to check if ISNULL returns as TRUE.

So this also means that the following will check to see if the attribute is populated:

 

If IsNull(objRecordset.Fields(1).Value) = False Then

   Do whatever

End If

or

If NOT IsNull(objRecordset.Fields(1).Value) Then

   Do whatever

End If

 

This is because IsNull(objRecordset.Fields(1).Value)  checks the value of the field and either returns as TRUE if there is nothing there, or FALSE if there is something there.

That makes me wonder, why isn't there just built in function called IS, or DOESEXIST. That would be more natural. I mean, when you check for a file it's usually something like

If objectFileSystem.FileExists(PathToFileName) then

   Do Whatever

End If

 

But alas, we are stuck with ISNULL.

At least we have something...  even if it is nothing :-)

posted @ Thursday, December 27, 2007 2:24 PM | Feedback (42)
Article Categories
Archives
My Links