Newbie Question

  • 4.7K Views
  • Last Post 27 February 2009
smsadm posted this 21 February 2009

We are upgrading our phone system (Unity (from Cisco) 4.2 --> 5).This
requires an AD schema update.
We're a relatively new company.
8000 seats.
Not much AD experience.
We're not trying to be too anal about this, but we do know that if AD gets
screwed, we're in a big mess.

Is there a preferred way to apply this upgrade to minimize any damage?
We do not have a lab environment (I know, I know ... We've tried)
We won't have time to set one up either.

How can we minimize any potential damage if something goes wrong?
How do you do it?

Thx in advance

--
smsadm

Order By: Standard | Newest | Votes
ZJORZ posted this 21 February 2009

>>>> How can we minimize any potential damage if something goes wrong?

>>>> How do you do it?



<sarcasm-mode=on>

Make time to built test environment and build one. Then test schema update

<sarcasm-mode=off>



You need to get real here!

>From your own saying: You do not have the experience and if it gets screwed you're in a lot of trouble



Amongst others, those are AT LEAST 2 reasons to have a test environment and to test what you want to do



Sorry, but not having a test environment and not making time for it is BS.





Met vriendelijke groeten / Kind regards,



Ing. Jorge de Almeida Pinto

Senior Technical Consultant

MVP Identity & Access - Directory Services



* This posting is provided "AS IS" with no warranties and confers no rights!

* Always test before implementing!

show

kennedyjim posted this 21 February 2009

I have never seen that put so well. Everyone should tell that to the holders of the purse strings and then they get ownership of the responsibility.

Well said Mr. Hacherl.

show

Gil posted this 21 February 2009

I'll try to leave the sarcasm out of this and look at the problem pragmatically. If there is no way to build a test environment, then you need to look at the risks and mitigate them as best you can.

The AD schema was meant to be extended, so generally there are no problems with it. Personally, I've never had a problem extending the schema, but I do know that some people have. The risks fall into four areas that I can think of:

1. A problem with the schema extensions themselves. Does the vendor provide an LDIF file? Is it correct? Does it use a unique OID subtree?

2. A problem with the schema extensions when installed in your environment. Have you already extended the schema for some other purpose? Are there any conflicting OIDs, or attributes or classes? Are there any conflicting changes to existing classes?

3. A problem with the replication process between DCs. Are all the DCs replicating properly, with no errors? Are the event logs otherwise clean?

4. A problem with the schema extensions and your applications. Do you have any AD-integrated apps? Do the new extensions touch any classes or attributes used by those apps?

To mitigate 1 and 2, you could pull a DC off the production network and put it in its own environment (remove the metadata from the production AD) and try installing the schema extensions. When you're done, flatten the DC and repromote it into the production forest. You might want to do this outside of production hours.

To mitigate 3, you can use DCDIAG and other AD utilities to make sure replication is working properly. Make a change to the Config NC, e.g. create a new dummy site, and make sure it replicates everywhere.

There's not much you can do to mitigate 4 without making the extensions in a test environment and running the applications. So that's a bit of a gamble without testing. Does anyone care if some of your applications just stop working for a while, possibly a long while? Be sure to tell them before you extend the schema that their applications may stop working and there won't be much you can do about it other than recovering the forest from backup.

Make sure that you have a forest recovery plan in place, and that you make a couple of DC backups. Depending on the size of your environment, a forest recovery plan can take several hours to many months to develop, but you really need to do this before extending the schema. If you only have a few DCs, it isn't too complicated. The forest recovery itself can take anywhere from several hours to several weeks, again, depending on your environment. Make sure you allow time to recover the forest if the schema extension process goes wrong, and make sure that everyone understands the network will be unavailable during the recovery process. The MSFT forest recovery whitepaper provides some useful information for developing a recovery plan.

If you do all of these, you will have reduced the risk as best you can without a test environment. You might break existing applications, but there's really no good way to tell that without testing, so the risk there is indeterminate. But if the schema changes DO break your apps, you can recover the forest... assuming you have a forest recovery plan that works. But how do you know the recovery plan will work without a test environment? In my experience, forest recovery plans never work the first time around, so the time required to recover the forest is indeterminate as well.

Even without the sarcasm, this doesn't sound like a good idea, does it?

Really, it shouldn't be that big a deal to build a test environment. Is there a server you can install either VMWare or Virtual Server on, even if only for a few days? Then you could build enough of a test environment to verify the schema extension process and app compatibility. It's something you could probably do over the weekend or a few days at most, and it shouldn't cost you any money if you can repurpose an existing server for a while.

Good luck. Backup your DCs. At least you'll have a slight chance to recover your forest if the schema extension goes wrong.

-gil

show

its.mike posted this 21 February 2009

VMWare is a life saver. Again and again.

show

jppmendes posted this 21 February 2009

http://support.microsoft.com/kb/888794/
Considerations when hosting Active Directory domain controller in virtual
hosting environments

:)


2009/2/20 Mike Mitchell <its.mike@shaw.ca>

> VMWare is a life saver. Again and again.
>
>
>
> From: ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] On Behalf Of *sms adm
> *Sent:
Friday, February 20, 2009 1:59 pm
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] Newbie Question
>
>
>
> Thanks for the detail. I really appreciate it.
>
> I will have answers to some of your questions soon.
>
>
>
> I am working on my boss. Just gonna take some time.
>
> As you can tell, I have been pulled into this and have more experience with
> SMS than AD.
>
> I also have Exchange DR in which I am also a newbie.
>
> That is really a bear, but I digress ...
>
>
>
> Thx
>
>
>
> smsadm
>

show

freemj1 posted this 21 February 2009

Have you considered standing up a new domain for the Cisco Call Center stuff? That was out solution as Cisco won't support Call Center on an ADAM instance and I wanted to keep third party application data out of our production AD forest.

...John Freeman

show

joe posted this 21 February 2009

ADAM with the schema analyzer tool would provide a means to get your current
AD schema into ADAM and then test adding the new Cisco schema to ADAM. This
would help validate 2 (and maybe 1 in terms of simple correctness although
not in terms of improper use of any specific identifiers like OIDs).

The barrier to doing this is rather low (you could run this on an XP
laptop), although you will end up dinking around with ADAM for a while to
figure out how to do this stuff if you have no experience with it.

Doing this should at least give you a clue if the schema mod is actually
likely to fail when you run it. Don't forget to make sure your forest
recovery plan is ready to roll though. :) You needed to have that ready
anyway....

Joe K.

show

tonyszko posted this 21 February 2009

Gil Kirkpatrick wrote:
> You mean setting up a new forest, right?
>
>

He may mean new forest or new domain ... I don't know why but Cisco
partners who comes into house often suggest such setup to put separate
domain into existing forest just for Cisco Unity purposes .... I've seen
several such installations made at customer sites.

--
Tomasz Onyszko
http://www.w2k.pl/ - (PL)
http://blogs.dirteam.com/blogs/tomek/ - (EN)

show

michael1 posted this 21 February 2009

In the "old days" (I was a Cisco certified unity systems engineer v1), when
"everyone" thought that the AD domain was the security boundary, Cisco
recommended a separate domain as a best practice in larger deployments (they
had small/medium/large deployment guides - sound familiar?). And actually,
for several companies I worked with, the AD rolled out for a standalone
Unity solution was the first AD they had.

Anyway, that recommendation was removed for CUSE v2 I think it was, but the
prior recommendation wasn't ever rescinded that I recollect.

show

gabriel/tfi posted this 21 February 2009

LOL! I will re-use this comment! – Gabriele.

show

sbradcpa posted this 21 February 2009

Question from the peanut gallery.

If you want a plan to recover from a botched schema update, what's your
plan for

a. hardware failure
b. bad patch
c. disk corruption
d. drive failures

Isn't the bigger ask here a solid backup and recovery plan (preferably
with a nice checklists during those times that you are going "Oh @#%@!?

What is your strategy now for those "Oh @#%$!" moments now?

Gabriele Scolaro wrote:
>
> LOL! I will re-use this comment! – Gabriele.
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of *Don Hacherl
> *Sent:
venerdì 20 febbraio 2009 22.08
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Newbie Question
>
> I have to make a comment here, as I've heard this too many times. You
> do, in fact, have a lab environment. What you do not have is a
> production environment.
>
> DonH
>
> ------------------------------------------------------------------------
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of *sms adm
> *Sent:
Friday, February 20, 2009 11:57 AM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] Newbie Question
>
> We are upgrading our phone system (Unity (from Cisco) 4.2 --> 5).
>
> This requires an AD schema update.
>
> We're a relatively new company.
>
> 8000 seats.
>
> Not much AD experience.
>
> We're not trying to be too anal about this, but we do know that if AD
> gets screwed, we're in a big mess.
>
> Is there a preferred way to apply this upgrade to minimize any damage?
>
> We do not have a lab environment (I know, I know ... We've tried)
>
> We won't have time to set one up either.
>
> How can we minimize any potential damage if something goes wrong?
>
> How do you do it?
>
> Thx in advance
>
>
> --
> smsadm
>

show

ken posted this 21 February 2009

If you lose a single DC, you can usually work through what's required to fix that even with limited skills (just build a new DC with the same or even a different name. Stick in a CNAME if required). It's not perfect, but it will solve 99% of issues.

If you lose your entire AD, you are in a much worse situation, especially when you have a non-trivial sized business (8000 users).

Now, the chances of losing the whole AD are very, very small (if AD is working properly at the moment). But the pain is much, much worse. If you have to get 50 DCs working again, how long are you apps going to be offline? If you are a 24x7 shop (e.g. running call centers or working round the globe) how much outage can you afford?

Doing a schema change can require a lot more than what you'd need for bringing back a DC due to hardware failure, depending on how paranoid you are.

Cheers
Ken

show

bpuhl posted this 22 February 2009


If organizationally you are left with no alternative, then there are some white papers you can download from Microsoft around "Active Directory Schema Change Processes" and "AD Forest Recovery", etc... Not to mention the non-MS papers that others have written. Gil has the one he and Guido did posted here: http://www.gilkirkpatrick.com/Blog/post/2008/12/NetPros-Authoritative-Guide-to-Active-Directory-Disaster-Recovery.aspx

In the absence of anything else, you should at minimum look at them and see if/where/how you can apply the knowledge to your environment. You're still going to be a test pilot, but at least then you're starting off with generic whitepapers, rather than completely empty documents.

Brian Puhl
Microsoft IT

show

listmail posted this 23 February 2009

Yep, I too agree that virtualization is a great answer to the "I don't have
a production environment because I am too busy running production out of my
lab environment" dilemma. While I am not a fan of virtualization in
production, I think it is a dandy solution in a lab when the excuse is there
is no money for hardware.


--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm





show

listmail posted this 23 February 2009

Cisco plays well with AD? That is the first time I have ever heard that. I
know my own experiences don't bode well with Cisco and AD. When I had to
work on stuff for those vendors I couldn't figure out who misused AD worse,
Cisco or EMC. In every case of Cisco Unity in any large environment I have
seen they have been in their own forest and the AD guys didn't even want to
touch that forest with a stick.

Maybe they got better though.


--
O'Reilly Active Directory Fourth Edition -
http://www.joeware.net/win/ad4e.htm

show

bdesmond posted this 23 February 2009

I haven't seen any evidence that Cisco has improved in this regard.

Thanks,
Brian Desmond
brian@briandesmond.com

c - 312.731.3132

show

jamesawells posted this 23 February 2009

I think the point might be that a Cisco Unity schema prep plays well
with AD/doesnt break anybody.

Letting Unity actually have any rights over an OU in your main
forest...THAT doesn't play nicely.

And Cisco IPCC is just scary.


--James

show

mcasey posted this 23 February 2009

In response to Joe, Brian, and James,
What challenges have you seen with Cisco living in the primary user
account domain? We currently run Unity in a separate child domain. I
hear there is a plan here to merge voicemail with email, then have a
single user account to do the unified messaging type o' thing.

I'd be interested to hear what issues others have faced with Unity.
It was already implemented here before I arrived so I did not get to
see what risks, challenges, etc we accepted along the way.

-matt

show

jamesawells posted this 23 February 2009

Unity did okay. I just didn't like giving it too many permissions
because the code is pretty buggy. I usually gave permissions to its
service accounts myself, rather than let it have full control and
assign them itself (which is what the documentation says, IIRC).

IPCC was another story. "AD integration" meant that it made an IPCC OU
and a huge number of nested OUs under that, all storing application
data in the description attribute of the OU. Horrible.

Both add a ton of new attributes to user objects. Including a lot of
things that should really be in the application's database. I've never
understood their design decisions.

--James

show

smsadm posted this 23 February 2009

We have this setup now and my original questions is for the Unity 4.2 -->
5.x upgrade.
With Unity 4.2 the only problem we have is when we inadvertently move the
Unity mailbox in Exchange (chg. of message stores, etc.), Unity has a
problem and the Message Light doesn't properly show. Don't know if this is
a problem with 5.x. We'll know soon.
Thx

show

Show More Posts
Close