Scheduled Task, VBScript, CDO, and Public Folders   

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

date: 23 Feb 2007 14:30:32 -0800   author:   unknown

Re: Scheduled Task, VBScript, CDO, and Public Folders   

"karl@geekclan.com"  wrote in 
news:1172269832.444799.207310@j27g2000cwj.googlegroups.com:
> 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. 

 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

date: Mon, 26 Feb 2007 12:41:54 -0800   author:   Dan Mitchell

Re: Scheduled Task, VBScript, CDO, and Public Folders   

On Feb 26, 12:41 pm, Dan Mitchell  wrote:

>  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

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...

date: 26 Feb 2007 14:21:24 -0800   author:   unknown

Re: Scheduled Task, VBScript, CDO, and Public Folders   

"karl@geekclan.com"  wrote in 
news:1172528484.784597.11350@t69g2000cwt.googlegroups.com:
> 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
> 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."

 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

date: Mon, 26 Feb 2007 16:38:52 -0800   author:   Dan Mitchell