I am trying to access the public folder store from .net. Using the following 
code:

            object mv = System.Reflection.Missing.Value;
            string pi = System.Net.Dns.GetHostName() + "\n" + 
System.Environment.UserName;

            MAPI.Session oSession = new MAPI.Session();
            oSession.Logon(mv, mv, false, true, 0, true, pi);

            MAPI.InfoStores oStores = (MAPI.InfoStores)oSession.InfoStores;
            MAPI.InfoStore oStore = (MAPI.InfoStore)oStores.get_Item("Public 
Folders");

But this gives the error about not found. If I list the count of the 
infostores, I only have one (the administrator (who I am logged in as) 
mailbox.) Any idea why I cannot access the PF store?

I assume it's the way I am logging on... any clues appreciated.

"JamesB"  wrote in
news:47fa20d3$0$32043$da0feed9@news.zen.co.uk: 
> oSession.Logon(mv, mv, false, true, 0, true, pi);
> [....]
> Any idea why I cannot access the PF store?
> 
> I assume it's the way I am logging on... any clues appreciated. 

 That's because dynamic profiles don't support public folders, basically 
-- you're telling CDO1.21 (oh, and don't forget that isn't supported in 
.Net, see http://support.microsoft.com/kb/813349) to create a temporary 
folder pointing at the mailbox you pass in.

 So the system does exactly that, but the temporary profile _only_ 
contains the message service for the mailbox. To get at public folders, 
you'll have to log into a real profile which has the public folder service 
in there.

 -- dan

"Dan Mitchell"  wrote in message 
news:Xns9A79565AA4017djmitchellayahoocom@207.46.248.16...
> "JamesB"  wrote in
> news:47fa20d3$0$32043$da0feed9@news.zen.co.uk:
>> oSession.Logon(mv, mv, false, true, 0, true, pi);
>> [....]
>> Any idea why I cannot access the PF store?
>>
>> I assume it's the way I am logging on... any clues appreciated.
>
> That's because dynamic profiles don't support public folders, basically
> -- you're telling CDO1.21 (oh, and don't forget that isn't supported in
> .Net, see http://support.microsoft.com/kb/813349) to create a temporary
> folder pointing at the mailbox you pass in.
>
> So the system does exactly that, but the temporary profile _only_
> contains the message service for the mailbox. To get at public folders,
> you'll have to log into a real profile which has the public folder service
> in there.
>

Thanks - figured it was probably something along those lines...

I have outlook on the machine so I can do that, the question then is, can I 
create a "real" profile without something like Outlook being installed?

Hi Dan,

> "JamesB"  wrote in
> news:47fa20d3$0$32043$da0feed9@news.zen.co.uk:
>> oSession.Logon(mv, mv, false, true, 0, true, pi);
>> [....]
>> Any idea why I cannot access the PF store?
>> 
>> I assume it's the way I am logging on... any clues appreciated.
> 
> That's because dynamic profiles don't support public folders,
> basically -- you're telling CDO1.21 (oh, and don't forget that isn't
> supported in .Net, see http://support.microsoft.com/kb/813349) to
> create a temporary folder pointing at the mailbox you pass in.

You are correct about the unsupported CDO part but aside from
that you should be pretty much see the public folder store no
matter if you are using an explicit or dynamic profile.
I use it in several scenarios.

I could think of two reasons why you have no public folder
access:
1) you connect to Exchange 2007 which might have been
installed without any PF
2) your mailbox is living in an Exchange Server which has
a PF database but the PF content is not replicated to that
server.

So in case of 2) you might need to create a mailbox on a
server which has PF database with all content. You will need
to add your windows account on that mailbox to give it
send-as and receive-as permissions. Thats enough to
logon to that mailbox. Now you should see the PF content
as well.

--
SvenC

"JamesB"  wrote in
news:47fa3238$0$32056$da0feed9@news.zen.co.uk: 
> I have outlook on the machine so I can do that, the question then is,
> can I create a "real" profile without something like Outlook being
> installed? 

 Yup. See http://support.microsoft.com/kb/306962. Don't forget that, 
depending on where your code is running, your code may not see the same 
bit of the registry as an interactive account, so the profile may not be 
valid for your code even though you can see it when logged in. (see 
MAPI_NT_SERVICE argument to MapiLogonEx)

 -- dan

"SvenC" <SvenC@nospam.nospam> wrote in news:C0F60CEB-C495-446B-845A-
BC56B2E74364@microsoft.com:
> You are correct about the unsupported CDO part but aside from
> that you should be pretty much see the public folder store no
> matter if you are using an explicit or dynamic profile.
> I use it in several scenarios.

 Really? How are you logging in when you're using dynamic profiles?

 I don't get it even running as a normal interactive-desktop app:   

Dim s As New MAPI.Session
s.Logon profileinfo:="server" & vbLf & "mailbox"
Dim i As MAPI.InfoStore
For Each i In s.InfoStores
    Debug.Print i.Name
Next

 gives me "Mailbox - Daniel Mitchell", and nothing else, which is what 
I'd expect.

Dim s1 As New MAPI.Session
s1.Logon "my profile"
Dim i1 As MAPI.InfoStore
For Each i1 In s1.InfoStores
    Debug.Print i1.Name
Next

 gives me "Mailbox - Daniel Mitchell", "Public Folders", "Personal 
Folders", "Archive Folders", because in the second case it's a real 
profile with all the other message services in there.

 -- dan

The standalone version of MAPI (which is PF-less servers aware) does not add 
the PF store to the list of the session stores 
(IMAPISession::GetMsgStoresTable) until it has a chance to hit the server 
(i.e. open the primary mailbox) to verify that the PF store actually exists. 
Unfortunately CDO 1.21 caches the list of stores when Logon is called and 
will never refresh it no matter what.
Try to create a second instance of MAPI.Session and set its MAPIOBJECT 
property to that of the first instance after your code accessed the primary 
store using the first instance of the session object.

-- 
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy  - Outlook, CDO
and MAPI Developer Tool
-
"SvenC" <SvenC@nospam.nospam> wrote in message 
news:C0F60CEB-C495-446B-845A-BC56B2E74364@microsoft.com...
> Hi Dan,
>
>> "JamesB"  wrote in
>> news:47fa20d3$0$32043$da0feed9@news.zen.co.uk:
>>> oSession.Logon(mv, mv, false, true, 0, true, pi);
>>> [....]
>>> Any idea why I cannot access the PF store?
>>>
>>> I assume it's the way I am logging on... any clues appreciated.
>>
>> That's because dynamic profiles don't support public folders,
>> basically -- you're telling CDO1.21 (oh, and don't forget that isn't
>> supported in .Net, see http://support.microsoft.com/kb/813349) to
>> create a temporary folder pointing at the mailbox you pass in.
>
> You are correct about the unsupported CDO part but aside from
> that you should be pretty much see the public folder store no
> matter if you are using an explicit or dynamic profile.
> I use it in several scenarios.
>
> I could think of two reasons why you have no public folder
> access:
> 1) you connect to Exchange 2007 which might have been
> installed without any PF
> 2) your mailbox is living in an Exchange Server which has
> a PF database but the PF content is not replicated to that
> server.
>
> So in case of 2) you might need to create a mailbox on a
> server which has PF database with all content. You will need
> to add your windows account on that mailbox to give it
> send-as and receive-as permissions. Thats enough to
> logon to that mailbox. Now you should see the PF content
> as well.
>
> --
> SvenC

Hi Dan,

> "SvenC" <SvenC@nospam.nospam> wrote in news:C0F60CEB-C495-446B-845A-
> BC56B2E74364@microsoft.com:
>> You are correct about the unsupported CDO part but aside from
>> that you should be pretty much see the public folder store no
>> matter if you are using an explicit or dynamic profile.
>> I use it in several scenarios.
>
> Really? How are you logging in when you're using dynamic profiles?
>
> I don't get it even running as a normal interactive-desktop app:
>
> Dim s As New MAPI.Session
> s.Logon profileinfo:="server" & vbLf & "mailbox"
> Dim i As MAPI.InfoStore
> For Each i In s.InfoStores
>    Debug.Print i.Name
> Next

Seems to depend on the CDO version: when I use the ExchangeCDO package I do
only get the mailbox. When using ExchangeMapiCDO on a machine without
Outlook I do get the PF store.

Unluckily Dmitry suggestion of using a second CDO object and initializing 
its
MAPIOBJECT didn't work for me.

I read the stuff about CONNECT_IGNORE_NO_PF flag again and I am not
sure that this is the correct behaviour:

http://blogs.msdn.com/jeffga/archive/2007/08/07/cdo-changes-to-work-better-when-accessing-mixed-exchange-2003-2007-servers.aspx

I would expect that when I use the ExchangeCDO package with Outlook 2007 to
connect to an Exchange Server 2003 I would get the PF by default.

--
SvenC

What is your code that sets the MAPIOBJECT property? You really need to make 
sure that the first session opens the primary store. Opening the Inbox 
folder and reading the number of messages there should do the trick.

-- 
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy  - Outlook, CDO
and MAPI Developer Tool
-
"SvenC" <SvenC@nospam.nospam> wrote in message 
news:8B652043-ABE9-4201-969E-96F7F7407591@microsoft.com...
> Hi Dan,
>
>> "SvenC" <SvenC@nospam.nospam> wrote in news:C0F60CEB-C495-446B-845A-
>> BC56B2E74364@microsoft.com:
>>> You are correct about the unsupported CDO part but aside from
>>> that you should be pretty much see the public folder store no
>>> matter if you are using an explicit or dynamic profile.
>>> I use it in several scenarios.
>>
>> Really? How are you logging in when you're using dynamic profiles?
>>
>> I don't get it even running as a normal interactive-desktop app:
>>
>> Dim s As New MAPI.Session
>> s.Logon profileinfo:="server" & vbLf & "mailbox"
>> Dim i As MAPI.InfoStore
>> For Each i In s.InfoStores
>>    Debug.Print i.Name
>> Next
>
> Seems to depend on the CDO version: when I use the ExchangeCDO package I 
> do
> only get the mailbox. When using ExchangeMapiCDO on a machine without
> Outlook I do get the PF store.
>
> Unluckily Dmitry suggestion of using a second CDO object and initializing 
> its
> MAPIOBJECT didn't work for me.
>
> I read the stuff about CONNECT_IGNORE_NO_PF flag again and I am not
> sure that this is the correct behaviour:
>
> http://blogs.msdn.com/jeffga/archive/2007/08/07/cdo-changes-to-work-better-when-accessing-mixed-exchange-2003-2007-servers.aspx
>
> I would expect that when I use the ExchangeCDO package with Outlook 2007 
> to
> connect to an Exchange Server 2003 I would get the PF by default.
>
> --
> SvenC

"SvenC" <SvenC@nospam.nospam> wrote in
news:8B652043-ABE9-4201-969E-96F7F7407591@microsoft.com: 
> Seems to depend on the CDO version: when I use the ExchangeCDO package
> I do only get the mailbox. When using ExchangeMapiCDO on a machine
> without Outlook I do get the PF store.

 Okay, that makes sense -- I'm talking to Exchange 2003 and it looks like 
I'm using the version of CDO1.21 from Exchange 5.5, so I'm a long way 
behind the times here.. :)

 -- dan

Hi Dmitry,

> What is your code that sets the MAPIOBJECT property? You really need
> to make sure that the first session opens the primary store. Opening
> the Inbox folder and reading the number of messages there should do
> the trick.

I missed the part of accessing the inbox. You are correct, when I use this 
one:

logonTest.vbs:

Dim oCDO, s
Set oCDO = createobject("mapi.session")
ocdo.Logon , , 0, -1, 0, -1, "exServer" + chr(10) + "mailAlias"
s = ocdo.inbox.name ' this line important

Dim oCDO2
Set oCDO2 = CreateObject("mapi.session")
ocdo2.MAPIOBJECT = ocdo.MAPIOBJECT
Msgbox ocdo2.InfoStores.Count ' here I get 2

--
SvenC

"Dan Mitchell"  wrote in message 
news:Xns9A7994375A019djmitchellayahoocom@207.46.248.16...
> "JamesB"  wrote in
> news:47fa3238$0$32056$da0feed9@news.zen.co.uk:
>> I have outlook on the machine so I can do that, the question then is,
>> can I create a "real" profile without something like Outlook being
>> installed?
>
> Yup. See http://support.microsoft.com/kb/306962. Don't forget that,
> depending on where your code is running, your code may not see the same
> bit of the registry as an interactive account, so the profile may not be
> valid for your code even though you can see it when logged in. (see
> MAPI_NT_SERVICE argument to MapiLogonEx)
>

That looks handy, will read up on that once I've managed to get the property 
adding bit I'm doing working...
Thanks

James