microsoft.public.exchange2000.admin - Schedule Free/Busy

Author

Schedule Free/Busy - coexisting

Micheled

2002-10-30, 12:23 pm

In order for Schedule Free/Busy to work in a coexistence
environment between Exchange 5.5 and Exchange 2000; Do I
necessarily need to have a PFCA in place, or can I just
point the mailstore of the Exchange 2000 server to the
Exchange 5.5 Bridgehead server that has the Schedule
Free/Busy system folders on it?

Richard Chen [MS]

2002-10-31, 1:23 am

Hi Michele,

Thank you for the post.

I suggest you create a Public Folder CA, for the object's replication. By
pointing the default public folder store to the Exchange 5.5 public
information store, it may cause problems since the Exchange 5.5 public
folder objects are not replicated to Active Directory.

Hope it addresses your concerns.

Thanks & Regards,

Richard Chen,
Microsoft Online Support Professional

Get Secure! - www.microsoft.com/security

==============================
=======================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
==============================
=======================
This posting is provided "AS IS" with no warranties, and confers no rights.

Micheled

2002-10-31, 10:23 am

Richard, I have several issues that need to be addressed
with the PFCA, that I'm very cautious in
just "introducing" one. Here they are:

Zombie users - we need to run the DS/IS adjust prior to
putting any PFCA in. It's not too late to do this,
Microsoft just recommends to do this when the first
Exchange 2000 server is introduced (so it should have been
done 2 years ago when the first SRS server was
introduced). The understanding of how Public Folder
hierarchies work is huge!. DS/IS needs to be run. Ie:
All public folder servers in legacy can get re-homed,
which is a huge and pain staking process to fix. The
ConfigCA does not replicate Referral and Affinity
information between Active Directory and Exchange 5.5.
Exchange 2000 users will use referrals, Exchange 5.5 users
will use affinities.

2. User permissions - how user permissions are actually
viewed in ESM during the time of co-existence. Operations
will need to understand PtagACLData, and what happens to
the ptagNTSD and ptagAdminNTSD. These are new terms and
new philosophies for them to understand. If permissions
have not been successfully converted previously then there
is a potential that no one will be able to access a public
folder server. There are a lot of known issues around
this area. There is a false sense of security when viewing
the client permissions in ESM, it will show the
permissions correctly but if you look at the actual
ptagACLData the "real" permissions are set differently.
I'm developing a test case just on this section since it's
the area that basically can make or break the PFCA
introduction. I still think just pointing the MS Exchange
Information stores to the legacy Public Folder server is
the best route still. There is a lot to get Operations up
to speed on here with the introduction of the PFCA's in
the short time that we have.

3. When an Exchange 2000 mailbox store has a public
folder store created on the server (which are servers do),
the hierarchy is automatically replicated to this server
from Exchange 5.5. Because the SRS servers were the first
Exchange 2000 server introduced, we need to check there to
see if the public folder hierarchy has been already
replicated.

4. Because we don't have any Exchange 2000 connectors in
place (Routing Group Connectors or SMTP Connectors), we
will have to remove the Disallow Public Folder Referral
setting from the 5.5 connectors through ESM. Exchange
2000 users will not be able to access the content by
default.

5. There are a series of event log id's that we can
monitor for in the documentation already. For example,
9551 gets registered each time a folder is accessed. The
E2k user will not be able to see the folder until the
problem is fixed.

The issue with the DN matching to the SID, we use Aelita
to move our user accounts to protect the SID history so
users can access legacy NT domains, as well as legacy
Exchange services. I need to understand more on the
mapping the PFCA does to the user attribute here. There
is a huge whitepaper that was introduced at MEC this year
that simple states "don't introduce PFCA's into your
enviornment until you fully understand the impacts" As
well as there are certain steps and percautions that need
to be taken before your first Exchange 2000 public folder
server is introduced. As from the threads I see here,
there are a lot of folks having problems with Public
Folders, and caution is the course to take.

>-----Original Message-----
>Hi Michele,
>
>Thank you for the post.
>
>I suggest you create a Public Folder CA, for the object's
replication. By
>pointing the default public folder store to the Exchange
5.5 public
>information store, it may cause problems since the
Exchange 5.5 public
>folder objects are not replicated to Active Directory.
>
>Hope it addresses your concerns.
>
>Thanks & Regards,
>
>Richard Chen,
>Microsoft Online Support Professional
>
>Get Secure! - www.microsoft.com/security
>
> ==============================
=======================
>When responding to posts, please "Reply to Group" via
>your newsreader so that others may learn and benefit
>from your issue.
> ==============================
=======================
>This posting is provided "AS IS" with no warranties, and
confers no rights.

Rich Matheisen [MVP]

2002-10-31, 4:23 pm

"Micheled" <Michele.deo@eds.com> wrote:

>Richard, I have several issues that need to be addressed
>with the PFCA, that I'm very cautious in
>just "introducing" one. Here they are:

A PFCA is required for mail-enabeled public folders. It has nothing to
do with public folder replication or permissions.

> Zombie users - we need to run the DS/IS adjust prior to
>putting any PFCA in. It's not too late to do this,
>Microsoft just recommends to do this when the first
>Exchange 2000 server is introduced (so it should have been
>done 2 years ago when the first SRS server was
>introduced). The understanding of how Public Folder
>hierarchies work is huge!. DS/IS needs to be run. Ie:
>All public folder servers in legacy can get re-homed,
>which is a huge and pain staking process to fix. The
>ConfigCA does not replicate Referral and Affinity
>information between Active Directory and Exchange 5.5.
>Exchange 2000 users will use referrals, Exchange 5.5 users
>will use affinities.

The need to run the DS/IS consistency check is to remove the zombies,
not to adjust any other data. You only need to check the box to remove
the non-existant users.

You can do this at any time (and you should do it periodically while
you're in mixed-mode).

>2. User permissions - how user permissions are actually
>viewed in ESM during the time of co-existence. Operations
>will need to understand PtagACLData, and what happens to
>the ptagNTSD and ptagAdminNTSD. These are new terms and
>new philosophies for them to understand. If permissions
>have not been successfully converted previously then there
>is a potential that no one will be able to access a public
>folder server. There are a lot of known issues around
>this area. There is a false sense of security when viewing
>the client permissions in ESM, it will show the
>permissions correctly but if you look at the actual
>ptagACLData the "real" permissions are set differently.

Another thing to watch for is nested distribuion lists being used in
5.5 to ACl a public folder. It's possible for a containing group to be
converted to a security group but one, or more, of the contained
groups may not be converted. This can lead to some interesting
situations.

>I'm developing a test case just on this section since it's
>the area that basically can make or break the PFCA
>introduction.

Not to belabor the point, but the PFCA shouldn't even be discussed.
It's got nothing to do with PF replication and ACLs.

>I still think just pointing the MS Exchange
>Information stores to the legacy Public Folder server is
>the best route still.

That's the route we took. The PF servers were the last to be moved to
E2K. The difficulty with this is that taking the PF machine down makes
the folders unvailable, even if there's a replica on another machine.

>There is a lot to get Operations up
>to speed on here with the introduction of the PFCA's in
>the short time that we have.
>
>3. When an Exchange 2000 mailbox store has a public
>folder store created on the server (which are servers do),
>the hierarchy is automatically replicated to this server
>from Exchange 5.5. Because the SRS servers were the first
>Exchange 2000 server introduced, we need to check there to
>see if the public folder hierarchy has been already
>replicated.

If it's got a PF store I'd be shocked if it hasn't been!

[ snip ]

>The issue with the DN matching to the SID, we use Aelita
>to move our user accounts to protect the SID history so
>users can access legacy NT domains, as well as legacy
>Exchange services. I need to understand more on the
>mapping the PFCA does to the user attribute here.

That's easy: there isn't any.

>There
>is a huge whitepaper that was introduced at MEC this year

That whitepaper is at least 18 months old. It may have been updated,
but it wasn't "introduced" this year.

>that simple states "don't introduce PFCA's into your
>enviornment until you fully understand the impacts"

The biggest of which is the introduction of huge numbers of duplicate
SMTP addresses into the AD.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

Sponsored Links