I thought it was about time to put together a quick scheduled task to ensure that all these “leavers” were automatically disabled and hidden from the Exchange address lists without IT manually having to do it.

I came across this handy and concise example, and modified it to run through a group of OUs while doing what I needed it to do.

Here’s the code. As always, run at your own risk, and test it before putting it into production:

On Error Resume Next

Dim arrLeaverOrgUnits, objOU
arrLeaverOrgUnits = Array("LDAP://OU=Leavers,OU=Sydney,DC=contoso,DC=com",_
                          "LDAP://OU=Leavers,OU=Melbourne,DC=contoso,DC=com")

For Each strOU in arrLeaverOrgUnits
  Set objOU = GetObject(strOU)
    ' Let's be extra-paranoid here, and make sure we're only working on the leavers OU
    '  in case someone adds the wrong OU into the array above
    If objOU.Name <> "OU=Leavers" Then Exit For

    ' Loop through each object in the current OU
    For Each objObject In objOU
      ' If the current object is a user
      If objObject.class="user" then
        'Disable the account
        objObject.AccountDisabled = True
        ' Hide the account from the Exchange address lists
        objObject.Put "msExchHideFromAddressLists", True
        ' Write the information back to the user object in AD
        objObject.SetInfo

        'WScript.Echo objObject.Name & " disabled and hidden from Exchange address lists"
      End if
    Next
  Set objOU = Nothing
Next

The problem is though, it’s impossible to remove the formatting on that number via the UI in Word. By default, the colour is set to “No Color”, but it’s impossible to go back to that setting once a colour has been chosen.

I didn’t want to re-create the entire document as it had macros embedded, and also had a lot of work done already. Luckily, all of this information is stored in XML format, so it’s not too hard to find.

To remove this style information from the number, do the following with a backup of your file.

1. Rename the file extension to .zip (I usually just append .zip to the existing filename)
2. Copy out the Word folder from within the zip file to somewhere temporary
3. Open numbering.xml from the unzipped word folder with something like XML Notepad
4. Search for the name of your style. In my case, it was “Heading1” (note the lack of a space between “Heading” and “1”. The style is actually called “Heading 1” in Word:
   
5. Once you find that style, drill down to the w:rPr node. You can see here that a style and colour is defined for the numbering associated with Heading 1
   
6. Remove everything under w:rPr except for w:rFonts->w:hint (I’m sure you could remove this too, but it was there by default for other styles)
   
7. Save the XML file
8. Copy the XML file back into the word folder in the zip file
   
9. Rename the file extension back to what it originally was. In my case, it was .docm
10. Open the file in Word, and inspect the result. Hopefully, it succeeds for you as it did for me:
    

Remember: Do this with a backup copy of your file in case you somehow manage to corrupt it.

We’re set up with TMG in our DMZ, which then sends traffic to a pair of CAS servers internally. We’ve been running Exchange 2010 SP2 and 2003 in co-existence for some time now, as some of our national offices are still in the process of migrating users across.

Our troubleshooting covered all areas, from looking at ActiveSync logs from IIS, running the Test-ExchangeConnectivity scripts, to testing on the devices themselves – you name it, we tried it. Here’s a quick way to turn up the logging level on ActiveSync using PowerShell:

Get-EventLogLevel | Where-Object {$_.Identity -like "MSExchange ActiveSync*"} | Set-EventLogLevel -Level High

The usual suggestions of permissions on the user account in AD and various other settings were not relevant. We even investigated the possibility that the problem could be caused by users still on iOS 4.0, which was known to cause issues and unusually high server load.

We then noticed that the TMG box would experience timeouts when requesting DNS resolution from our internal DNS servers. There were also errors from the TMG connectivity verifiers for AD that the LDAP servers were unreachable. This pointed to some sort of connectivity issue between TMG and and the CAS servers. Circumventing the TMG box by VPN’ing in or connecting via our corporate WiFi seemed to resolve the issue.

Upon inspection of our Netscreen 25 firewall, we noticed a lot of error messages about the source IP session limit being exceeded:

This is by design. It turned out that our DMZ had previously had IP based session limits set to a threshold of 128 sessions. This limit was being exceeded by the large number of ActiveSync users we now have. We bumped up that number to 512, and our problems are now resolved.

Funnily enough, while I was troubleshooting this issue, two ActiveSync troubleshooting-related articles appeared in my RSS reader of choice, Google Reader:

1. The Exchange Team Blog: A script to troubleshoot issues with Exchange ActiveSync
2. MSExchangeGuru.com: Troubleshooting Exchange ActiveSync and reading IIS logs

They’re both certainly worth reading, and are a great starting point if you’re experiencing ActiveSync issues.

Send-MailMessage  -Subject "Test email"
                  -To "recipient@contoso.com"
                  -From "me@contoso.com"
                  -SmtpServer mail.contoso.com
                  -BodyAsHtml (Get-Content "d:\templates\invite-template.htm" | Out-String)

In addition to making it look more presentable, I also discovered that you can inject code into the <head> of the index page. This allowed me to achieve what I’d wanted to do for a while on that site – track visitors using Google Analytics.

To do so you already need to be using indexes and FancyIndexing. Then, simply add the following to your .htaccess file:

IndexHeadInsert "<script type=\"text/javascript\">var _gaq = _gaq || [];_gaq.push(['_setAccount', '{INSERT TRACKING CODE HERE}']);_gaq.push(['_trackPageview']);(function() {var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);})();</script>"

Here’s the rest of my .htaccess file, excluding the security section:

Options +Indexes

IndexOptions +FancyIndexing
IndexOptions +FoldersFirst
IndexOptions +XHTML
IndexOptions +HTMLTable
IndexOptions +SuppressRules
IndexOptions +NameWidth=*
IndexOptions +SuppressDescription

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t /resources /cgi-bin

IndexStyleSheet "/resources/style.css"

IndexHeadInsert "<script type=\"text/javascript\">var _gaq = _gaq || [];_gaq.push(['_setAccount', '{INSERT TRACKING CODE HERE}']);_gaq.push(['_trackPageview']);(function() {var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);})();</script>"

Although I’d previously deployed Vista and Windows 7 using MDT 2010, I’d never seen this problem. The issue occurred with a captured HP ProBook x86 Windows 7 Professional build.

I had to edit the unattend.xml for the task sequence in question, and delete the Display section from oobeSystem –> x86_Microsoft-Windows-Shell-Setup_neutral. Once this was done, the strange default of 1024 x 768 (where did that come from?) was no longer applied, and Windows Setup detected and set the maximum resolution.

Doing so comes up with an error:

Performing operation "generate" on Target "Catalog".
The operation failed to complete.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentNullException: String reference not set to an instance of a String.
Parameter name: source
   at System.Globalization.CompareInfo.IsPrefix(String source, String prefix, CompareOptions options)
   at ?A0xfe36268f.ConvertToNtPath(String path)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.CbsSessionAdaptor..ctor(String bootDrive, String imageWinDir, String servicingPath)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.OfflineImageImpl.InitializePackages()
   at Microsoft.ComponentStudio.ComponentPlatformInterface.OfflineImageImpl..ctor(OfflineImageInfo imageInfo)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.Cpi.PlatformImplementation.CreateOfflineImageInstance(OfflineImageInfo imageInfo)

The captured image I was trying to work with was of a 32-bit machine, and the WAIK tools I have installed on my desktop are the 64-bit ones.

The solution, as I learned here after a bit of searching, is to re-run the catalog operation on an x86 machine.

As you can’t install the 32-bit tools on a 64-bit machine, I installed the 32-bit tools on my laptop, fired up WSIM, opened the WIM image, re-ran the catalog operation, and it succeeded without errors.

You’d think that they could catch the exception and give you a useful message about running the catalog again on a compatible machine, but no…

$printers = Get-WmiObject Win32_Printer

if ($printers.Count -eq 0) {
    Write-Host -ForegroundColor red "No Printers Found"
    exit
}

foreach ($printer in $printers) {

    if ($printer.Local -and $printer.Shared)
    {
        Write-Host -ForegroundColor Green "Cancelling all jobs on: $($printer.Name)"
        $printer.CancelAllJobs()

    }
}

It will only clear print jobs on local printers that are shared out. There’s some more info about the Win32_Printer class and the CancelAllJobs method on MSDN.

Note that I haven’t included any error-checking in this script at all, so run it manually first to see if it will work. As always, run at your own risk.

To schedule it, simply create a new scheduled task:

1. Run with highest privileges
2. Run whether user is logged on or not
3. Do not store password
4. Action: Start a program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
5. Arguments: -File “C:\path-to-script-file\name-of-script-file.ps1″