Scheduled Task, VBScript, CDO, and Public Folders

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

karl@geekclan.com - 23 Feb 2007 22:30 GMT

Trying again... =)

I have a small VBScript application that uses CDO to scan posts in a
public folder and move them to an achive folder if they are old. It
works great when I run it myself or from any account that has
permissions. The problem is it fails when I try to run it as a
Scheduled Task.

The Scheduled Task is running with a domain user account that has the
correct permissions.

Initially it would not even log into the session. I found that this
had
to do with the user not being logged in so the registry hive was not
loaded which is required for profiles. So, I altered the session
logon
line to create a temporary profile. This works better but not fully.
The script logs in and is able to grab the 'Public Folders'
information
store but for some reason it does not see any folders under the
'Public
Folders' rootfolder. Normall there would be 'Favortes' and 'All
Public
Folders'.

I am not sure if this is still an extension of the registry problem
or
not.

Is there a way to have the script 'login' as the user so the registry
loads?

Any guidance would be great. I rather not create a service for this.
Hmm, wonder if I will have the same issue there?

Thank you!
Karl

Reply to this Message

Dan Mitchell - 26 Feb 2007 20:41 GMT

> So, I altered the session
> logon
[quoted text clipped - 4 lines]
> 'Public
> Folders' rootfolder.

Assuming you're using the profileInfo parameter to Session.Logon,
that's to be expected. The temporary profile you create that way only
has the services added for connecting to the mailbox you pass in, and
public folders aren't stored in your mailbox.

The problem you're hitting with the scheduled task is that accounts
running as NT services (ie, scheduled tasks in this case) don't see the
registry the same way as desktop applications, so even if you have a
profile existing under your account when logged in normally, that
profile may not exist when the code's running as you as a service.

Possibly the easiest way to do this is to enable anonymous access to
public folders, then use something like the code at the bottom here:

http://support.microsoft.com/kb/195662

-- dan

Reply to this Message

karl@geekclan.com - 26 Feb 2007 22:21 GMT

> Assuming you're using the profileInfo parameter to Session.Logon,
> that's to be expected. The temporary profile you create that way only
[quoted text clipped - 13 lines]
>
> -- dan

Thank you but I would not be able to open up the Public Folders that
way, they need the permissions they have. I did do some more searching
and found this entry on the MSDN website:

"If your application is running as a Microsoft® Windows NT® service,
you cannot access the Microsoft Exchange Public Folders through the
normal hierarchy because of a notification conflict. You must use the
InfoStores Fields property to obtain the Microsoft Exchange property
PR_IPM_PUBLIC_FOLDERS_ENTRYID, property tag &H66310102. This
represents the top-level public folder and allows you to access all
other public folders through its Folders property."

I am going to see if this helps at all...

Reply to this Message

Dan Mitchell - 27 Feb 2007 00:38 GMT

> Thank you but I would not be able to open up the Public Folders that
> way, they need the permissions they have.

Okay, sorry.

> "If your application is running as a Microsoft® Windows NT® service,
> you cannot access the Microsoft Exchange Public Folders through the
[quoted text clipped - 3 lines]
> represents the top-level public folder and allows you to access all
> other public folders through its Folders property."

The problem is that that propery is stored on the info store _for the
public folders_. Try looping and dump out all the info stores you have
-- I'll be very surprised if you have more than just one called "Mailbox
- user".

If you can get a profile with the public folders store in it, then you
could use that property on the public folders store to find the ENTRYID
for the root of the public folders, but these are more useful for
possible multi-language problems where "Public Folders" may not be the
right string to use.

-- dan

Reply to this Message