Re: Incoming E-Mail - cant create contact in OU
- From: "callahan" <cacallahan@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 2 Sep 2007 13:42:18 -0400
Okay, lets see here, you are having problems getting DMS to work and you
already have the application pool delegated rights to the OU. It worked
when you had that account set as a domain admin for the domain, but not when
it is a local admin.
In my experience it is because you didn't quite delegate enough rights to
the account in the OU.
Also though, before we go further with that, Daniel was wondering if you
would delegate the same rights you gave the application account to the OU to
the account that is being used for the central administration application
pool.
(Actually, come to think of it, this does bring us to a little empass.
There is a question we need to ask, and that is if you are running WSS 3 as
a single server install or a Web Front end, server farm install?)
I took it for granted (and probably so did Daniel) that you had a server
farm installation of WSS because your application pool account was a domain
account. I'm going to stay with that assumption until you tell us otherwise.
If your installation of WSS 3 is not a single server installation, then the
application pool account for Central Administration (which is considered the
Farm account because it also is the account that runs the Sharepoint Timer
Service, and is critical to the functioning of a sharepoint server farm)
also may need access to the OU. You can figure out what account that is a
couple of different ways: check what account identity the Sharepoint Timer
service is running in the services MMC; or open IIS, go to the Central
Administration's application pool's identity is.
Once you figure out what that account is, you could try delegating it rights
to the OU. Specifically, don't forget to delegate it delete rights so it can
delete things from the OU if need be.
Overall, I suspect that what happened was that you did not delegate enough
rights to your web application's application pool at the OU. Instead of
using the delegate control wizard, you might want to go to the View menu in
the ADUC MMC and select Advanced features. That will let you, when you
right click the OU, go to properties and see the Security tab (that you
can't see without the advanced features view enabled). In the security tab
you can see the permissions that are available. Check the domain admins
rights, then click the Advanced button at the bottom. Notice that the
domain admin actually has much more than just the standard full control of
the OU (which is above what you might've given the account originally--
while a domain admin they get stuff that trumps that delegate control you
gave it), they have control of all child objects under the OU as well (not
because domain admins explicitly get that but because they are members of
the Administrator's group that gets that). It's the domain admin like
control that you need to give the app pool so it can do its work with the
OU-- *without* giving it that kind of control elsewhere in the domain.
Please check that out and see if it works for you. Don't give up hope, I
have it working with Exchange 2003 in several places without the application
pool being a domain admin. The permissions on this thing are tricky but it
can be done.
So-- make sure you application pool for your web application that contains
the sites that will using incoming email has the correct advanced rights for
the OU.
-- make certain that your central administration app pool account has rights
to the OU.
-- make certain that you do an IISRESET /noforce after you make any changes
to the settings in the OU or in sharepoint. You will not see any results of
your changes in sharepoint for up to 15 minutes (in my experience) after you
make them unless you force it by using IISRESET.
-callahan
"Paul" <Paul@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FFBE285C-FF21-4CC5-910C-73D74F2677C9@xxxxxxxxxxxxxxxx
I apologize if I dont understand your suggestion. My current/initial setup
is delegating the application pool rights to the OU, and that doesnt seem
to
work.
Today I have added the application pool account as a local administrator
to
all my WSS 3.0 boxes, and rebooted the boxes to be entirely sure.
I then enabled email, and logged into my sharepoint site and attempted to
add an email to a discussion and it still fails.
I am pretty sure its an AD/OU issue, not a local WSS issue. Reason?
Because
if I add the Application Pool user to Domain Admins, it then works. There
is
something missing in AD or possibly Exchange rights that is not allowing
WSS
to create the contact in an OU. Again, to confirm - I am delegating
rights
to the new OU for my sharepoint application pool user account.
"Daniel Bugday" wrote:
Paul,
i think you have to follow callahans suggestion of adding the account to
the
local admin froup of that server.
Could you try one other thing..
Try to delegate permission to the account which is running the IIS pool
for
the central administration site without adding to admin group and then do
an
IISReset.
/Daniel Bugday
"callahan" <cacallahan@xxxxxxxxxxxxxxxxxxx> wrote in message
news:%23NTN2SR7HHA.4436@xxxxxxxxxxxxxxxxxxxxxxx
The application pool account, in my experience, must be a local admin
of
the sharepoint server that is doing incoming email and hosting DMS.
Also
the account must have those permissions to all the child objects for
that
OU as well.
In addition, if you are going to do approval for the groups, I found
that
I had to give the farm account rights to the OU as well in order to be
able to delete a group. Please let me know if that is the case for you.
Frankly, I am impressed. I personally have never gotten it to work
with
Exchange 2007.
-callahan
"Paul" <Paul@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E9308C36-1A8C-4071-93EB-BAB58A0C7DD8@xxxxxxxxxxxxxxxx
Running Windows 2003 R2 AD, Exchange 2007 and WSS 3.0.
I have WSS website application pool running as a domain user account,
not
network service.
I created an OU called Sharepoint and delegated rights to this user
account
(Create, delete and manage user accounts + Read All User Information).
When I create a site and attempt to enable email, it gives me "Error
in
the
application. "
However to prove its a permission issue, I then added this website
application pool account to domain admins, rebooted my WSS to be sure
and
tried again - now it works! Obviously I dont want to run this as
domain
admin, so removal of domain admin kills the ability to add email.
There must be other AD OU permissions that are not listed in the
Microsoft
instructions to make this work, but what?
.
- Follow-Ups:
- References:
- Re: Incoming E-Mail - cant create contact in OU
- From: callahan
- Re: Incoming E-Mail - cant create contact in OU
- From: Daniel Bugday
- Re: Incoming E-Mail - cant create contact in OU
- From: Paul
- Re: Incoming E-Mail - cant create contact in OU
- Prev by Date: Re: Incoming E-Mail - cant create contact in OU
- Next by Date: Re: Incoming E-Mail - cant create contact in OU
- Previous by thread: Re: Incoming E-Mail - cant create contact in OU
- Next by thread: Re: Incoming E-Mail - cant create contact in OU
- Index(es):
Relevant Pages
|
