|
Ha, that was easy J From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Figueroa, Johnny There was no real reason for a separate domain, other than it
simplified the vendor's support. We ended up creating an OU and delegating
administration to it. Thanks.... I promised I would get back to you From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe I completely understand. If a vendor is actively and completely supporting this application
for you ***as a service*** then patching, etc should be something that you
specify the requirements for in the actual contract with the vendor with
penalties, etc associated with it for non-compliance. You should not have
to touch any of it because you shouldn't even have the ability to touch any of
it - that is what the service model is about. If this is a vendor telling you to create a new domain/forest that
you in any way shape or form have to support for their app, I would tell them
they better have a really amazing explanation because all of the tables
are already against them and if the extra domain/forest gets pushed through you
immediately tell, not ask, the people requiring the application what it is
going to cost to get the extra resources to support the extra domain/forest -
including all licenses for monitoring and other third party tools needed to
properly support the environment. Again, if this is just an application and application support, you
tell the vendor where it goes. If this a service, then listen carefully to the
vendor as they may have a good point and if you force them to deviate there
will be a premium at the minimum associated with it. A new Domain/Forest for a
service model should be a black box to you. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Figueroa,
Johnny Joe, I can not comment on the specifics just yet
as IT has not actually met with the vendor yet. We received the
requirements and when I read about the separate domain with a trust to our own,
I started to try and build a case for NOT. As I had mentioned earlier. I will try to keep an open mind on the whole thing but if every
medical vendor came in and asked for their own domain we would have quite a
mess. You then end up with problems like patch compliance, virus definitions
you can not verify or having to provide for some form of isolation of these
environments while allowing them to be functional. This last part turns into
administration overhead and dollars that we try to push back to the vendor, not
always successfully depending on how much the application is needed. Vendor supported environments inside your own can be a post all of
its own that goes on forever. How many vendors say they will take care of their
devices and you wake up one day only to find out that you are under attack from
one of those vendor "supported" devices. It could be a virus as we
have had happened to us or a misbehaving AV application on the same devices you
don't have admin access to that renders several DFS servers inaccessible with
high CPU usage. We will try to get to the bottom of it as usual, the devil is in
the details. I promised to report back since many of you have taken the time to
provide your thoughts on the matter. Thanks From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe My first reaction is that that is pretty nebulous and hazy. I don't
think they can compare whatever it is they do to a respirator and have
validity, I think that would be talking apples and olive pits. Overall it sounds like a move to reduce support and troubleshooting
costs by having a known fixed environment in which their app will run. It could
even mean that they have bad decisions (and coding) in the software itself that
has hard requirements to that specific layout so they don't have to code for a more
generic setup. Certainly the concern that AD may not be stable is a valid one from
a vendor doing managed service support standpoint as it is something I have
encountered in the field myself. More environments than not that I have
walked into to deploy Exchange the AD folks thought AD was perfectly fine and
were surprised when Exchange dragged their DCs under water and I have to go
through their design and figure out what exactly isn't optimal (hint usually
the disk subsystems - stop using mirrors damnit). But if the customer is
willing to accept that risk as a caveat to the support model then the vendor
should be able to support it. This can and usually should have some level of
impact on costing and possibly support levels and penalties (if they exist). It
is cheaper to run support on a fixed known setup than it is to support
something you didn't design and can't exercise control over. You as a customer
would need to accept that as well. But it really comes back to whether the
product will work in a generic environment at all and if the vendor is willing
to put in the time to figure out their exposure and write the
contract (and bill) to suitably cover for it. Taking this back to an Exchange example which is more familiar to
many folks. Take the example where you want email and you bring someone in
to create and run an Exchange service for you. You aren't managing or
supporting it, it is all them, you simply give them the requirements. If
they have a cookie cutter separate domain/forest solution it is something they
have worked out and tested and understand and can best support. In general I
think it is better for you and think it is good for you to strongly
consider allowing them to run it that way because of the issues with
Exchange and the resulting administration mess. It is tough to fight it because
there aren't a lot of options outside of Exchange with the features people
want... If you have strong feelings against that separate forest and
want the vendor to forgo their own design, which does happen, they
can and usually will run it from your forest however you have got to
expect cost increases. You are basically telling the respirator company
(to use that bad analogy) that you want the respirator to work in an entirely
different way than the product you picked out of the catalog. The prices increases are to cover real costs incurred by the
vendor to cover a changed support model and cover for the extra design
work that they would need to be involved in to support your
environment. In addition, you would need to accept the caveats on
service that they may need to put into place to protect themselves from
lawsuits that are actually the fault of something they don't control. An
example would be any issues that end up having a root cause back in the AD
that you control releases them from SLA penalties and allows them to charge
back costs associated with it. A specific example is say where you have company
A running a mail service for you out of your directory and you allow local site
admins to have extensive control over their users and one of the admins decided
to give himself a 10GB quota and then uses it and kills the free space on the
Exchange server causing the vendor to scramble resources to cover for the
resulting issues. That absolutely needs to be charged back to the company and
not the vendor. Even if you have separate groups in the same company running AD
and Exchange those are things that get fights going over because the Exchange
team is budgeted to cover Exchange issues and the AD team is budgeted to cover
AD issues and some person who wasn't involved with either breaks one. So those examples are primarily from the standpoint that the
vendor is doing all of that support. If the vendor is just coming in to
build something for you and you will be supporting it, it is all about what you
want which is why you will tend to see a different viewpoint on this between
folks doing managed services and folks just doing consulting and
implementation. There are long term considerations for managed services that
consulting won't be around to worry about. And to toss in a few random thoughts... On the positive side if you
deside to dump that app later, it is quite easy to snip it off and not have
stuff to cleanup in your "real" forest but on the negative side if
the vendor goes out of business you could be in a bad way and end up trying to
find out how to bust into that forest so you can support it. So how much do you know about this actual application and vendor?
How many customers have you spoken with that are currently using it and are
they all configured the same way? Is the vendor going to be running that
environment for you and if so how important is it that they do? Do you know
about any schema requirements or anything else that you might be screaming
about later and saying you don't want near your forest? Will the application
run off of an ADAM instance instead of a full blown forest? joe
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Figueroa,
Johnny Thank you all. The vendor in question is bringing in a medical solution. Here is
the response from the vendor so far. Mind you that we have lots of medical
device solutions that exist in our domain, the FDA card is played as a blanket
so you stop asking questions... we ran into the same issue with security
patches. "why can't I patch that device?". When we've looked at these
FDA regulations in the past it turned out that there was more liability by not
patching. From the vendor: "Let me start by thanking you for considering our support
model and continuing to pursue supporting it in your organization. Our
designers have architected the system to comply with Microsoft’s best
practices. We have implemented our own XXXX.local domain in an effort to
provide solid system integrity founded on Kerberos authentication and a single
sign-on experience for your clinicians. Our
system relies heavily on the integrity of the Active Directory structure. We
have integrated the launching of services and control of processes using this
Microsoft recommended model. It has
been our experience that relying on a hospital’s Active Directory structure is
a dependency that has opened our customer’s up to liabilities for the integrity
of our XXXX regulated medical device. I liken the servers to a respirator.
Having an outside person, no matter how qualified, work on a respirator would
be a concern from a clinical standpoint. We have witnessed Group Policies
applied to servers in a more open environment. This is a liability we do not
want to expose our business partners to. Any change, no matter how minute to
our system, would endanger our validation and designation as a XXX
regulated medical device and would open you to failing FDA auditing." Thanks From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe I would tend to agree except in the case of Exchange, I am ALL FOR
Exchange being run in a separate single domain forest, it solves an incredible
number of problems such as the GC/NSPI problems as well as administrative
isolation, etc. The exception there is if Exchange is deployed in a
decentralized fashion out to all of the sites you already have DCs at, at
that point, you probably want to fight with the issues with it in the main
forest. The biggest complaint I have seen for running a separate Single
Domain Forest for Exchange is around provisioning and quite frankly, that
really isn't all that involved and doesn't necessarily need a full blown
MIIS/IIFP solution. It depends on what data is needed where. If you
need all of the GAL info in the main NOS forest as well as the Exchange forest
then you looking more into metadat sync tools unless your provisioning is all
being handled through a centralized mechanism and then that can be used to send
the info in both directions and actual tie between the domains for syncing
isn't necessarily required. But if this isn't Exchange, I would be curious to hear the details
of the app and why they want a separate forest. Most vendors if they told me
they did it in a stupid way that had that requirement I would beat and tell them
to fix it. With MSFT and Exchange, that only works a little bit. :) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier,
Guido I think everyone would be conceptually opposed - would be good to
hear the vendor's reasoning for this. What does the app do? What benefit do you have from running their app in a speparate
(single domain) forest? I can think of many downsides, but if the app is supposed to
protect really sensitive data (isolation scenario), this may potentially be the
reason for them to demand a separate forest. Certainly not, if the same folks
manage both forests though... So pls. aks them for more details - doesn't
hurt to understand their thinking. /Guido From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Figueroa,
Johnny We
are a 2003 Forest with an empty root domain and a single child domain. We have
a vendor looking to bring in a product that utilizes its own domain and has a
one way trust to our domain. I
do not know anything about the product yet but I am almost conceptually opposed
to these vendor domains. I am looking for pros and cons... really ammunition to
say no. Thanks Johnny Figueroa |
