I still get this error when I attempt to create a new group:
The Directory Management Service reported the following error: Access
denied.
Any help you can offer is greatly appreciated.
Thanks,
Candee
To start, that white paper, if I am not mistaken, was probably written by
Steve Smith and was about MOSS, right?
MOSS is different when it does DMS. It's got shared service providers to
help with that sort of thing. WSS doesn't have any of those.
Noqw, when you say you made the app pool owner the owner of the OU, what
exactly did you do?
Did you make the account that was the domain user account identity the owner
of the OU? Or did you delegate control?
Also I have found that making that account the local admin does bupkiss for
me.
There are two accounts at work here. If you enable request approval (which
I DO NOT suggest, it's what is causing me intermittent problems), you'll see
that the *content database account* is the one that creates the request, not
the central admin app pool. That is the account that I give local admin
rights on the sharepoint server.
So, what permissions/delgations did you give the central admin app pool on
the OU, and did you make the content database access account for the web app
a local admin? And, someone who posted about this earlier also had to
completely reboot the server to get it to work.
-callahan
"Candee" <can...@hotmail.com> wrote in message
news:O2lwFJu%23HHA...@TK2MSFTNGP06.phx.gbl...
"callahan" <cacal...@NOSPAM.computer.org> wrote in message
news:eE1e5au%23HHA...@TK2MSFTNGP06.phx.gbl...
>I have had that error before and it drives me nuts.
>
> To start, that white paper, if I am not mistaken, was probably written by
> Steve Smith and was about MOSS, right?
Nope; this was WSS oriented:
configuring incoming email settings:
http://technet2.microsoft.com/windowsserver/WSS/en/library/445dd72e-a63b-46d0-b92d-bcf0aa9d8d061033.mspx?mfr=true
>
> MOSS is different when it does DMS. It's got shared service providers to
> help with that sort of thing. WSS doesn't have any of those.
>
> Noqw, when you say you made the app pool owner the owner of the OU, what
> exactly did you do?
I delegated ownership; and when that didn't work, I went in advanced
permissions and made sure to give that account full access to that object &
all child objects.
> Did you make the account that was the domain user account identity the
> owner of the OU? Or did you delegate control?
Both
>
> Also I have found that making that account the local admin does bupkiss
> for me.
Definitely didn't help
>
> There are two accounts at work here. If you enable request approval
> (which I DO NOT suggest, it's what is causing me intermittent problems),
> you'll see that the *content database account* is the one that creates the
> request, not the central admin app pool. That is the account that I give
> local admin rights on the sharepoint server.
Ah, never thought of that. I will give it a shot.
Thank you so much!
I have found nothing online that really, seriously lays out exactly what to
do to get DMS to work with WSS. I wrote about it recently in a book, but
there are things (which I mentioned there as well) that still seem to be
waiting for a service pack. I can get it to work, and work fine, with
permissions for the central admin app pool and the content access database
as a local admin, but request approval still is a problem...
-callahan
"Candee" <can...@hotmail.com> wrote in message
news:OSSl2fu%23HHA...@TK2MSFTNGP04.phx.gbl...
"callahan" <cacal...@NOSPAM.computer.org> wrote in message
news:OHZx5yu%23HHA...@TK2MSFTNGP06.phx.gbl...
Think of it this way-- basically there are four accounts, or people if you
will that run Sharepoint. One is the Farm account, another is the Content
Database Access Account, and the other two work only in the Search
department; Search Service and Index Service.
To do DMS the Farm account needs access to the DMS OU because it is in
charge of Central Admin and adding settings and information about sharepoint
in the farm's configuration database. And the Content Database Access
Account (the web application's app pool account, in charge of accessing the
content database for the web app) is responsible for initiating the request
for the contact record or distribution list from its sites. It needs access
locally on the server to be allowed to do this (for some reason I have never
been able to figure out, truth be told).
So that means that the Farm account needs a lot of access to the DMS OU and
all child objects therein, and the CDA account needs local admin rights on
all sharepoint servers in the farm. If you add more web apps, and they use
their own app pool accounts, each one of them needs to be a local admin too.
I hope this helps,
-callahan
"Candee" <can...@hotmail.com> wrote in message
news:umkfm%23v%23HHA...@TK2MSFTNGP03.phx.gbl...
Ms. Callahan's book btw (for lurkers)
is this
http://wss.asaris.de/sites/walsh/Lists/WSSv3%20FAQ/DispForm.aspx?ID=947
(Mastering Windows SharePoint Services 3.0, Sybex)
and according to today's info on the Amazon US site (linked in the above
page along with other Amazon's), it's due out on November 5th.
Mike Walsh
WSS FAQ http://www.wssfaq.com
no questions by e-mail please
"callahan" <cacal...@NOSPAM.computer.org> wrote in message
news:OsaHRUy%23HHA...@TK2MSFTNGP04.phx.gbl...
I had hoped to get it out sooner but I got pneumonia at one point and lost
more than a month of edit time... November should be a hard date, barring
anything going wrong with the compositors and printers.
-callahan
"Mike Walsh" <englant...@hotmail.com> wrote in message
news:OUpmmg1%23HHA...@TK2MSFTNGP05.phx.gbl...
The default app pool was running under network service; I changed it to the
WSS account and viola!
Thanks so much for pointing me in the right direction.
I will make it a point to buy your book.
"callahan" <cacal...@NOSPAM.computer.org> wrote in message
news:usvhoV4%23HHA...@TK2MSFTNGP02.phx.gbl...
About the book; step by step stuff for DMS is in chapter 15, which is my
favorite chapter. Of course, it's a little late for you because you've
already figured it out <g> , but it's there in case you forget.
-callahan
"Candee" <can...@hotmail.com> wrote in message
news:uq%23D4F5%23HHA...@TK2MSFTNGP02.phx.gbl...
"callahan" <cacal...@NOSPAM.computer.org> wrote in message
news:u6GVOX5%23HHA...@TK2MSFTNGP05.phx.gbl...
I've been following this issue and working on it independently for a week or
so now and many of your suggestions have been helpful. However, some stuff
is still clearly wrong with my implementation.
First, I'm running MOSS 2007 with Exchange 2007. I have 2 web front ends,
1 index server, and an active/passive backend SQL cluster. Pretty much the
standard medium farm.
My central admin application pool account runs the central admin app, and
the timer service. It is a domain administrator.
My web application that I'm trying to configure email distribution lists for
runs under an unprivileged domain user account. Obviously, when I try to do
anything involving DMS, it bombs out and doesn't create the objects in the
AD. Against MSFT's best practices (and your suggestion), I make this account
a local administrator on the server that I'm running the SMTP service on.
Doing this, as you say, "makes it work" -- sort of. It has the permission to
create the distribution group in the OU once it has local admin on the box
and resolves Sharepoint throwing errors - but something is still not working
correctly. It does not actually populate the distribution group in the
Active Directory with any account information. So, if I send a test email
to this new distribution group, it's processed by SMTP properly and gets sent
to nobody. If I add user accounts manually into the "Members" field of this
distribution list, then the email gets sent properly.
I thought, well, I'll make the web application pool account a domain admin
and see if that solves the issue. Nope. Still no members populated in the
list.
You mentioned before that you "never got it to work" with Exchange 2007 -
was this the problem you were having or something else? I don't think
Exchange is part of the problem right now as it seems to be step 3 in a 3
step process (MOSS --> AD ---> Exchange) and right now it looks like the AD
isn't being affected correctly. Any ideas? I'm pretty close to opening a
support call with Microsoft on this issue if not.
As an aside, I share your frustration with the approval/rejection process of
distribution groups - is there any way to just disable that?
Does the app pool account have to be a local admin on _all_ servers in the
farm? Is it not populating the group with users because the account isn't an
admin on the database side, maybe?
It's extremely annoying that you have to go against best security practices
in order to make this stuff work.
Thanks in advance.
Realize that the AD objects actually get *made* by the Farm account in
Active Directory.
The web application account does not do that. Therefore you must use *both*
accounts in the correct way in order to get DMS to work.
And is this not entirely secure-- you betcha. That's what discourages both
myself and Candee.
Please let me know what permissions you applied to the OU. Check back
through my posts with Candee for more instructions.
-callahan
"bogglor" <bog...@discussions.microsoft.com> wrote in message
news:67D1503E-59BB-4E78...@microsoft.com...
So if the farm account is the account that creates the objects in the AD,
and merely adding the web application account to local admins is merely what,
for lack of a better term, "gets it to work" inside Sharepoint .... then this
makes no sense at all, given my setup. The farm account is a domain admin
with full control over the OU (I have advanced features checked in ADUC) and
every single one of the rights is marked as allowed.
Thanks for helping out with this; I really appreciate it.
I have never made the farm account a domain administrator. I have made the
web application adomain admin before (hmm, your web app account isn't a
local or network service is it??), but not the farm account.
Also, Bogglor, make absolutely sure that the farm account has all rights to
read, write, create, delete on the OU (permissions, objects, subtrees,
anything that can be created, read, written, or deleted) and all CHILD
OBJECTS in the OU.
And keep this in mind-- sharepoint is slow. Period. Do an iisreset /noforce
to speed it up, or even reboot (another poster on this board had to do that
to get DMS to work). But it can take five, ten, even fifteen minutes for
sharepoint to become aware of a permission change. Meanwhile, you've
assumed something didn't work and have moved on...
I can only tell you what has worked for me and others. There is another
frightening issue. I was helping someone here who said they were using
Exchange 2007. They got it to work, with the help of my instructions. I
never got to try it out again before I had to hand in a book I was writing,
so all I personally did was 2003. All the documentation says 2003 and 2007,
and because of the person I helped I believed it, so I went with that.
But what if that was a typo or mistake on the part of that someone in the
newsgroup and they didn't use 2007? Then my original opinion that it only
worked with 2003 is right and 2007 doesn't work with it.
Is anyone out there doing DMS in WSS 3 only and using Exchange 2007 to do
it?? Anybody?
Anyway, Bogglor, to review:
1) farm account must be a domain account. It must be added to the OU with
full read, write, delete, create privileges on the OU AND CHILD OBJECTS. I
am not sure what the domain account has explicitly on an OU created by a
different account.
2) web application account must be a domain account. It must have at least
local admin rights on the sharepoint servers in the farm (and as I've
mentioned, I am not certain as to why).
3) DO NOT enable request approval. You DO NOT need it. So don't do it, it
causes problems.
4) consider, after an iisreset /noforce, a reboot of the sharepoint server,
as that helped someone else.
5) also, check your event logs, and the sharepoint logs in the 12 hive to be
sure there is nothing else going on.
6) check back in and let us know what happened.
Meanwhile-- I'll see if I can rustle up a exchange 2007 server and see if I
can finally test and see if it works with that version. And either way we
can meet back here.
-callahan
"bogglor" <bog...@discussions.microsoft.com> wrote in message
news:0AB4B19D-6D1C-4ACC...@microsoft.com...
I've been working on getting exchange 2007 to work with DMS.
Whatta pain. One of the problems is that recipient update services has be
removed
(see:http://technet.microsoft.com/en-us/library/79df6a3a-29a8-4935-b143-8a66c8d082d4.aspx
for more). It can be forced to work though, so that's the direction I am
taking.
On top of that, the set up the SMTP connector you have to have both an Edge
Transport role server and a Hub Transport role server, but not on the same
box--- so to test this I had to get another VM on my over stretched server
and then install Exchange 2007 on it.
I am still working on it, but I suspect that Exchange 2007 is going to be
too much of a pain to use with WSS 3 and DMS.
How are you doing?
-callahan
"bogglor" <bog...@discussions.microsoft.com> wrote in message
news:0AB4B19D-6D1C-4ACC...@microsoft.com...
The larger problem I have still remains - distribution groups are simply not
populating with account names. Can anyone confirm that this isn't the way
it's supposed to be? When you email enable a group on a Sharepoint site, it
should create a contact in your AD based on the alias you chose and then
populate that distribution group with the accounts that match the group
inside of Sharepoint, correct?
Right now I am caught up in finishing a project that is way beyond overdue
to be done. However, my research on it is that I was either mislead when I
was told that it works fine in Exchange 2007, or they did something to get
it to work and never bothered to mention what it was.
This is what I found-- at the heart of the problem is that Exchange 2007 no
longer has a recipient update service. I think that lack of a RUS is why
DMS will not work with WSS (how's that for acronyms). However, there is a
command line "cmdlet" that will let you manually do RUS. As soon as I get
out from under, I am going to set up a virtual environment in which I can
test this cmdlet and see if it is the magic bullet. It wasn't working for
me last week, but I think my install was bad (it didn't interact with AD
correctly).
Also, I mentioned the need for the farm account to have to have control of
child objects in the OU. That's why you need to do advanced permissions to
begin with, even with exchange 2003.
Too bad that giving permissions to that DLL didn't do the trick. It would
be sweet not to have to give web application accounts local admin rights
whenever you wanted to use DMS for that web app. Thanks for coming back and
letting us know what's going on.
By the way, you are aware that you don't have to do request approval, so
your distribution groups don't have to go to that page in Central Admin,
right? If you don't use that page, does it work? I've had access denied
issues on that before, with perfectly good Exchange 2003 networks, using
request approval.
-callahan
"bogglor" <bog...@discussions.microsoft.com> wrote in message
news:E2A73A28-788B-4676...@microsoft.com...