Cannot Create Scheduled Task Server 2003 R2

I hit a snag at work today while trying to create a scheduled task to run a batch file daily on a server.  The problem was after creating a scheduled task using the wizard, a popup displayed this:

The new task could not be created.
The specific error is:
0x80070005: Access is denied.
Try using the Task page Browse button to locate the application.

Of course, the task wasn’t created.  Googling around wasn’t much help…most of the stuff references Windows XP and a bunch of the results want you to go inside the registry.  I figured there must be a better way.  Something that all the posts had in common was saying that something had changed the permissions on the Windows Tasks directory.  So, I figured running CACLS to reset the permissions on that tasks directory should fix things.  I was right.  So this fix is MUCH simpler than all those forum posts and mailing lists posts said.

To fix:  Open up a command prompt and change directory to C:\WINDOWS.  Next issue the following command:

 CACLS Tasks /E /G builtin\administrators:F

it should echo back ‘processed dir: C\WINDOWS\Tasks’ and return you to a prompt.  After this, you should be able to schedule a task quite easily.  The skinny of this problem is that the tasks directory just gets its permissions wrong and you’re using CACLS to reset things.  Hope this helps someone out there!  It took me a couple hours to figure it out!

Exchange 2003 to 2007 Global & Universal Groups

I hit a snag that was a result of my conversion from Exchange 2003 to Exchange 2007.  The snag was with global groups.  The problem is that global groups cannot be expanded by Exchange…so if you have a distribution list that is a member of a global group it will be grayed out in the Exchange Management Console and you will not be able to edit it.  You also won’t be able to right click and convert it to universal because it will give you the error of:

A global group cannot have a universal group as its member

So what to do?  How does one convert this group to a universal one?  The problem doesn’t lie with the group  itself but with the membership of the groups.  In order to convert one, you have to convert them all.

The EXPTA blog has an excellent post regarding what is going on with solutions to boot:

As you may know, Exchange Server 2007 and Exchange Server 2010 force you to create all new distribution groups as universal distribution groups.
The reason for this is that Exchange 2007/2010 requires a local Global Catalog (GC) server in the Active Directory site where Exchange resides to query for group expansion. A GC can expand domain local, global, and universal groups. However, domain local groups (and sometimes global groups) can only be expanded within the domain local scope. If the GC is a member of the companyabc.com domain, it will be unable to expand a domain local group in the sales.companyabc.com subdomain.

I’m going to be posting how they solved their problem for posterity but you can head over to the EXPTA blog for the full post which contains much more meat than this post will.

To solve the problem, query the groups and look at how many you have that are global.  Just open up a command window on a domain administrator account and remember that this command may take a while on a large enterprise:

dsquery group -limit 0 | dsget group -samid -scope -secgrp > Groups.txt

Next run the command to convert the global groups to universal.  There are no adverse problems that will result from this…the conversion doesn’t mess with permissions.

dsquery group -limit 0 | dsmod group -c -q -scope u

You WILL have to run this 2nd command many, many times.  See, each time it cycles through the groups it finds the top level one it has not converted and converts it to universal…there may be 3 more subgroups that need converted but it won’t convert them until the parent is a universal.

For more explanation, see the EXPTA blog link above and hopefully this helps someone out!

How to Fix Ghost Delegates and List Delegates in Exchange 2007

The Problem of Ghost Delegates

There is a problem with Microsoft Exchange 2003 and delegates.  When users are deleted, their delegate or send on behalf attributes are not deleted with them.

This problem has been around since Exchange 5.5 and possibly before and it’s REALLY annoying.  Microsoft has a hotfix available for Exchange 2003…but the problem is, you have to know WHICH mailboxes the fix needs to be run on.  Top that off with my environment actually being Exchange 2007 and NOT 2003 and one might discover an even larger problem.

Let’s backtrack and define the problem with a little story:

Say you work for Acme Corp which has 1500 employees in a single forest environment running Exchange 2007.  John Smith, an employee of 10 years at your corporation has left for greener pastures over at Emca Corp.  John was a delegate with send rights on Frank Doe’s mailbox as he was Frank Doe executive assistant for almost all of those years.

When HR notified your Active Directory administrator that John Smith had left, they promptly disabled and later deleted the user…this may have happened while you were still using Exchange 2003.

Now you have a problem…John Smith has left the company and was a delegate on Frank Doe’s mailbox.  When someone sends an invitation to a meeting with Frank Doe or mail to a group that Frank Doe is a part of…they may get an Non Delivery Notice (NDR) similar to the following:

Smith, John
The recipient’s e-mail address was not found in the recipient’s e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.

_____

Sent by Microsoft Exchange Server 2007

This glitch is EXCELLENT for annoying users everywhere!  It’s also a potential problem as someone could mass email Frank Doe and potential generate a NDR in addition to each email they send.  If they were to identify a few more people who may have had this problem, the possibility of having twice the amount of email generated and thus, twice the amount of email traffic, is something that large corporations may not want to have in their existing Exchange environments.

Microsoft realized that they had a problem on their hands and released a fix that you apply to mailboxes that suffer from the ‘ghost delegate’ “feature”.  Great right?  This fix is of course for Exchange 2003…so if you’re using that, you’re set.  You still will need to know a major detail before proceeding though:

  1. How many mailboxes have this problem? (usual response)

Therein lies the major problem.  How do you identify which mailboxes have old ghost delegate cruft still floating around generating NDR’s all over the place?  Especially in smaller environments where EVERYONE was a delegate of everyone else?

It’s impossible.

You can try to identify which mailbox has the problem but you would have to use the process of elimination…not a very time saving process and definitely not something I want to do (imagine visiting 50+ users!).  Instead,  I elected to identify all current users with delegates on their mailbox because chances are that the ghost delegate was once a delegate of these identified users.  I plan on cross referencing these users with a distribution list that is generating the NDR to properly identify the problem.  So, onward with how to identify the potential problem with a powershell query.

Identifying Problem Mailboxes with Powershell

Search the web, I’ve found many different ‘solutions’ to this problem with none of them getting things exactly how I needed them to be.  Some of the solutions would run a query and return information that was valuable…but not valuable enough.  Other queries should have worked but didn’t.

I’m by no means a powershell expert so I’m absolutely sure this little scriptlet can be improved.  It does the job though by returning anyone who has a delegate and listing who each delegate is.  So without further fanfare, the powershell command:

Get-Mailbox -resultsize unlimited | Where {$_.GrantSendOnBehalfTo -ne $null} | select Name, @{Name='GrantSendOnBehalfTo';Expression={[string]::join(";", ($_.GrantSendOnBehalfTo))}} | Export-CSV C:\SendOnBehalfTo.csv -noTypeInformation

Let’s break this command down.  The first portion Get-Mailbox -resultsize unlimited retrieves all user mailboxes and doesn’t limit to 1000 as is default with Exchange 2007.  We pipe this command into the next one with the ‘|’ symbol.  Here we use a conditional Where and select the attribute GrantSendOnBehalfTo returning only mailboxes from the first part of the command where said attribute is NOT null or empty.

Next, out of these mailboxes that don’t have the GrantSendOnBehalfTo attribute as empty, we select the Name of the user.  Now we should be able to stop here, however, we’re working with a string attribute here and returning Name will return a Multivalued property instead of the proper DN or user name we’re looking for (something like this Microsoft.Exchange.Data.MultiValuedProperty`1[Microsoft.Exchange.Data.Directory.ADObjectId] ).  To get what we need, we have to join the Multivalued property (string) with the results from the first half of the query.  To do this we create a commandlet and use the join command to bind the first part of our command to the multivalued property and translate that property into something readable for us.

It’s in the string conversion section that most people get frustrated with.  I know I got frustrated with it and used a portion of a commandlet for allowing a user or group to only accept messages from certain mailboxes…I just adapted that string conversion and join for my own purposes.  Like I said, I’m not extremely fluent in the ways of the powershell script…I just know that adapting it worked.

Identifying the Problem Mailboxes with Active Directory Queries

Of course, after spending 6-8 hours constructing my query in powershell I found a simple little tool from Joeware.net called “ADFind” that allowed me to execute a simple AD query and output all of the same information into a much more readable format than my powershell command.  If you’d like to do the same thing, head over to the ADFind page, enter your email and download the tool.  Extract it to your desktop and then open a command prompt and change directory to your desktop.  Next, enter a proper AD query with the adfind.exe prepended:

AdFind.exe -default -f "&((homeMDB=*)(publicdelegates=*))" publicdelegates > C:\delegates.txt

The output from Joe’s tool is MUCH nicer than what I was able to accomplish using powershell.  I’m sure someone will be able to take what I did with powershell and improve on it…but when there are handy tools like joeware provides, what need is there?

Implementing the Microsoft Fix

The ‘official’ fix from Microsoft is to install a hotfix if you’re running Exchange 2003.  Supposedly, Exchange 2007 doesn’t suffer from this problem…but there is a caveat there.  If, like me, you’ve upgraded from an Exchange 2003 environment that suffered from this problem…you migrate the problems with it!  So, I have an Exchange 2007 environment suffering from ghost delegates and NDR’s.

How to remedy this?  There are 3 directions provided.  The first from Microsoft is to go inside the tools >> options menu in Outlook and delete the delegate.  The problem with ghost delegates is that they aren’t there…which renders this fix completely useless.  The second solution is to launch Outlook with the /cleanrules switch.  The third solution out there is to use the MFCMapi Editor on the user mailbox that has the problem, find the hidden bits, and delete them.  The problem with this solution is most people AREN’T comfortable with editing the profile inside a snap-in…it’s much like using ADSIEdit to edit AD manually and can be overwhelming.

Examining the 3 options, it’s obvious that /cleanrules switch is probably the easiest to implement.  The problem is that it will delete ALL rules from the mailbox and if you have users who have been around for quite some time it means tons of rules.  The other problem is that it has to be run manually on EACH mailbox.  This of course is bad if you have an elaborate delegate system.

When we identified who has delegates with our queries above, we most likely found a culprit for who is having the problem and generating the NDR.  For me it was rather easy because I cross referenced my list of those with delegates with a distribution list.  When one of the unit secretaries sent email to this distribution group, it would also generate the dreaded NDR.  This means that a member of the distribution group has a ghost delegate.  Cross referencing gave me a list of 6 people to run the /cleanrules switch on versus the over 50 delegate mailboxes from the queries above…a much smaller number to visit.

I hope my confusing process can help someone out there and please improve on anything you see here…as I said, I’m by no means an expert…I just like to document my learning process to help others and also to remind myself of the fixes I find 🙂  Thanks for reading!

Migration Tip – XML Logs

When migrating from Exchange 2003 to Exchange 2007, I had problems with disk space on one of our network drives.  For the life of me, I couldn’t figure out what the problem was until we had about 100MB left.  Then I realized that every single mailbox move was being logged!  Try running a script that moves hundreds over at a time and then think of the log files!

I ran across a blog post that details just this and what to do about it.  Hopefully you won’t end up like me finding out after the fact!

http://www.telnetport25.com/component/content/article/11-exchmig/320-exchange-2007-tracking-and-analysing-large-mailbox-move-reports-using-the-exchangemovemailboxtaskviewer-tool.html

Moving Mailboxes from Exchange 2003 to Exchange 2007

During a migration from Exchange 2003 to Exchange 2007 many find that having 4 maximum thread transactions happening simultaneously is a bottleneck. Using powershell, one can increase the maximum number above 4 and save time and effort in the process.

During a migration from Exchange 2003 to Exchange 2007 many find that having 4 maximum thread transactions (default in using the Exchange Management Console) happening simultaneously is a bottleneck.  Using powershell, one can increase the maximum number above 4 and save time and effort in the process.

Some things to keep in mind during the migration:

  1. Tons of transaction logs will be generated and won’t be wiped until a backup happens…make sure you have space on your transaction log disks.
  2. Make sure your Mailbox Server has plenty of physical resources available to use during the move…RAM is a specific concern.  Always overshoot your estimates on how much RAM you need.
  3. Error reporting in the shell isn’t as intuitive as you’ll get using the EMC (Exchange Management Console)

My specific environment was moving from a single backend 2003 server to a single 2007 mailbox server.  The cmdlet that is posted can be used to move a mailbox database/storagegroup from one physical server to a another database/storagegroup on a different physical server.  I’ll go through what each section of the cmdlet means.

Get-Mailbox –Database “2003ServerName\StorageGroupName\DatabaseName” | Move-Mailbox –TargetDatabase “2007ServerName\StorageGroup\Database” –MaxThreads 10

The command above should be executed in powershell on your 2007 Mailbox Database Server.  The Get-Mailbox -Database command will tell Exchange where the mailboxes you are moving are coming from.   You then Move-Mailbox to a target database on the 2007 Mailbox Server.  The last portion of the command tells the command to increase the max threads of the command from 4 to 10.  Please make sure that you substitute in the server names, storage group names, and database names appropriately.

Remember that this will only move one database at a time…if you are like me, you like to take small steps in the process and verify that things look good after each small step.  Hopefully, this helps your migration take a little less time.

Creative Commons License
Except where otherwise noted, the content on this site is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.