I agree, autodl and autogroup aren't the answers, but they
were the closest MS has gotten to the answer for companies drowning in group
management issues such as the one I have most of my experience with.
I agree that if rubber stamping is all the validation that
is occurring, the company will have issues. But I also don't expect you can
properly quantify and programmatically handle every possible thing that a person
may want to bounce a group name for. Consider this, if you have some
administrative group that is going through and processing group requests already
including creating them, think of the work effort saved if they are now simply
saying yes or no to the creation or population (knowing that the admin groups
doing these two different tasks could be different). Slowly you add more and
more rules to bounce common bad requests until rubber stamp is just about all
that is needed, at that point then you have validated the system so that it
can run autonomously. I have done that with a couple of automated systems and it
tends to work well. This is admitting that no system from no company is going to
work well right off and that some level of tweaking will be required until
it is full-auto. Even then, occasional spot checks will be
needed.
I was thinking MSDE in the generic sense of what it was
supposed to be originally. A simple database tech that could be deployed with
apps that needed some measure of DB functionality. Something that didn't require
administration other than what the app applied to it. Of course, MSDE never
really made it to that point and became a nightmare for many companies. I am a
very vocal opponent of a full blown DB technology for being used with apps
unless the technology is taken into account fully during the architecting,
integration, installation, and daily maintenance which means full blown DBs
managing the technology besides the app. Most companies do not think about the
whole DB app in and of itself, they just think it makes a good backend. MS is
great for this illogical approach with MOM and MIIS, etc.
"Putting
tools that help you to manage your AD and or Exchange (let's just call
them applications you've already bought) should not come in a product
suite such as MIIS only."
Absolutely agree with this one. I don't think you should
need a SQL expert to properly manage your AD and that is exactly what MIIS will
require. I do understand the direction that they are (or possibly now it is
were) going with MIIS being the provisioning frontend for AD. Understanding it
doesn't mean I have to like it. I think it is a big mistake. AD should be able
to mostly stand alone, you want to front end it with MIIS, fine. Make that part
of the AD product and don't require SQL backend, use ESE or the AD itself.
I have recently spun up a folder under f:\dev\cpp called
adauto. I applied the Borland service wizard to it and now have a basic fleshed
out service for doing queries against AD and processing changes to that AD based
on what the queries return. The initial thought was just to put together a
solution people could point at when you hear the question "when someone gets
added to an OU, how do I make them part of a group" but then when I started
reading specs I had written down through the years I realized I wanted it to be
able to do more than just groups which is why it got the name adauto instead of
adautogroup. I figure I will try to make a fairly flexible tool which is
entirely based on and in the AD it is doing things for as I think there are
enough syncing apps out there already. I then hope to take that flexible tool
and make up basic tasks that people like to do such as add/remove users to/from
groups based on OU membership or other attributes. I have been promising myself
to write one since about the fall of 2000 and have been slowly adding notes to
the pile of things it can do. I guess I kept hoping I would never have to write
it, but hey... it is now almost 2006, fully 6 years after the release of 2K and
people are still saying the same things about a lot of this management. Possibly
I can work into it the idea of taking feeds from a web site as well to handle
group requests from the unwashed masses. If I do, that will be several revs into
it, I don't expect it anywhere near the 1.x versions. I want to answer the other
questions I have written down about things happening automatically based on
rules/triggers first.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Wednesday, December 28, 2005 11:04 AM
To: [email protected]
Subject: Re: [ActiveDir] OT: creation of Email and Security groups [through GUI no less]
MSDE = SQL2005Express isn't it?
I'd really prefer not to introduce yet another
DB technology into the mix if possible.
Joe, I think that some logic to prevent the
creation of too many sids is needed in the product regardless, but I think some
level of self-service is needed. I've seen too many processes that allow for the
'rubber-stamp' approval of group creation that I'd rather see a system that
enforces some of the rules and reports on exceptions vs. having a layer 8
process that just doesn't get the attention needed until long after it's a
problem. I can tell you from experience (and I'm sure I'm preaching to the
choir here) that few organizations have regulated the creation of group policy
the way they should until after it bit them either because of operational
problems or because of compliance issues. Some still won't address nor ack
that it's a even important after that (other than those that are required for
compliance of course.)
Autogroup was fine, but it still allowed for
groups of any name. I don't think that was such a hot idea for most
organizations. I wouldn't be surprised to find a group inside of MS that
was called something like "pigpen" or some other peanuts character. (Side note:
While many may not see that as a problem, if you have an international presence,
what seems fine in one culture won't be fine in another and may even be
offensive. )
Oddly, I've thought that something like this should be
available for years from the vendor (MS) but AutoDL and AutoGroup are not
the answers I had in mind if they were to do
that.
Putting tools that help you to manage your AD and or
Exchange (let's just call them applications you've already bought)
should not come in a product suite such as MIIS only. That would be
similar to buying from another large, blue company that Microsoft used to
write code for. That's a horrible model from my perspective and usually just
irritates me especially when you have a partner model vs. a "we'll build it
all" model for bringing products to market. That's because when
you have that type of market, you make "good enough" products that satisfy
the general need but allow room for creative and nimble third-party companies to
come up with great products. The issue here is whether I should have
to even go to a third party to manage what I already bought.
Anyway, if this doesn't make it, maybe we'll
have to have a look at writing a tool based on some of that. For now, it might
be good to move that to the back burner and see what already exists or can be
easily modified.
-ajm
On 12/28/05, joe
<[EMAIL PROTECTED]>
wrote:
The old MS Solution which just did DLs is called AutoDL and it has been available externally but as Al points out, depends on SQL Server. Then came AutoGroup which MS would not give out to anyone but handled Sec and Non-Sec AD groups, I know I tried for over a year to get it and was finally told all of this functionality was being wrapped into MIIS.... But again, that depends on SQL Server.If someone inside of MS intends to make yet another solution, I would highly recommend it not need SQL Server and that it handle AD and ADAM. Possibly it should use ADAM as its backend store? Alternatively it could use AD itself or MSDE (regardless of size of org) or ESE.I agree completely with Al on the group naming. Blood has been spilled over much less than names. Some of the biggest bloodiest corporate arguments I have been involved in have been about naming standards. I know of no large company that would allow end users to come up with their own names without rules around it. Even in a small company you could see a name like sbradleysucksmybutt or something like that which is obviously not a good thing in a corporate environment. Sure you will have logging of who did it once someone figures out it was done, but if you have 50,000 or 100,000 groups out there, who is doing that checking?Another thing, users shouldn't just be creating groups ad hoc. There needs to be a corporate strategy that walks you around the mine fields of having too many SIDS in your tokens or just plain replicating a bunch of crap that doesn't need to be out there at all. As Al indicated you definitely need a work flow where approval has to be gathered prior to the system just doing this.Other than that. As Al and Brian indicated, this has been a problem with many solutions through the years.
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al Mulnick
Sent: Wednesday, December 28, 2005 9:04 AM
To: [email protected]
Subject: Re: [ActiveDir] OT: creation of Email and Security groups [through GUI no less]
Wouldn't Tony already be aware of such things?DL/DG management is not a new issue by any stretch. It gets new life because the DG can now also be a SG which makes it more important to understand the ramifications of creating a new DG.The Dev team should well aware of such things and should also be familiar with the Microsoft solutions used in-house (which are not always available to the public).Personally, if they're going to roll a solution for group management, don't limit it to those using Exchange and therefore have DG's that are also SG's. Make it a group management function (preferred not to be based on expensive DB technology) that encompasses customers of AD (the common denominator). It would not bother me if there were added functions that you could get with Exchange deployed, but don't make it so you have to have it.Any solution created should have the ability to be self or centrally managed in an organization with 1 or more DC's and 1 to 500,000 users (or more?) There should be audit ability as well as the ability to send reminders and validation flows of group membership along with the ability to set business logic rules. An example of that would be to require an owner for every group created. That owner MUST have an account in the AD and it must be active. If not, there must be some sort of override else the group is automatically removed from circulation. This would help greatly with things such as SOX compliance as well as other compliance efforts. Another need to have would be the ability to have the creation of groups follow a pre-defined naming standard. Nice to allow users the freedom to create groups with any name they wish, but that doesn't help with the greater good in an organization over 100 people. Surprisingly (not really) if you put 100 people in a room and ask them to come up with meaningful names for groups, you'd get 101 names for the same group you're going to create. That would be fine in a Yahoo! setting but for corporate use it's unpredictable and next to impossible to manage or worse, troubleshoot. Good naming standards are the responsibility of the corporation's architects and it's up to those standards creation processes to come up with meaningful and useful naming standards. Not the consumers of the service. At least, not if you intend to keep the service available and able to be troubleshot in a timely manner. Besides, who would win if two equal folks decided they wanted the same name for a group? Sword fighting duels are not legal in most countries any longer :)The list goes on, but there are many things that this type of tool can be useful for. I think many of the third party solutions that are mentioned later in the thread are very good, but if Microsoft is going to create such a product, they should consider what it's intended uses are and balance that against what exists and what problems their customers need to solve. They should also consider the implications of creating a product that competes with their partners.Finally, Susan, if you know Tony, you might suggest that he talk with the Exchange and AD product teams. I'm sure they have somebody who is aware of the issues and the currently available solutions from partners. It's possible there's still some room for additional solutions, but it would be good for him to research with them to avoid overlap where it may not be needed.Then again, what would I know about it? ;-)
On 12/27/05, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] < [EMAIL PROTECTED]> wrote:Got a list? You might want to ping Tony so he doesn't reinvent the
wheel :-)
Brian Desmond wrote:
>Tools exist form MS in the past, 3rd party, and in many large orgs home baked stuff...
>
>Thanks,
>Brian Desmond
> [EMAIL PROTECTED]
>
>c - 312.731.3132
>
>________________________________
>
>From: [EMAIL PROTECTED] on behalf of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>Sent: Tue 12/27/2005 9:42 PM
>To: [email protected]
>Subject: [ActiveDir] OT: creation of Email and Security groups [through GUI no less]
>
>
>
> http://blogs.technet.com/secguide/archive/2005/12/27/416528.aspx
>
>MSSC is looking into the possibility of a solution/tool to help with creation and lifecycle management of email and security distribution groups
>
>* Creating and managing groups within an organization requires unnecessary administrative overhead.
>* Administrators use valuable time creating groups that could otherwise be used for other IT activities.
>* End-user productivity may be hampered by delays in processing requests for creation of groups.
>* End users find it frustrating that they cannot create and manage groups that have meaningful names and users find it hard to manage especially for adding and removing users.
>
>The proposed solution would provide end-users with the ability to create and manage groups through a simple self-help Web portal.
>
>
>
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
