Re: Some simple questions...

not only that... reading the books is almost a must because the exams ask
questions based on what is in the books.

my experience with the exams is that sometimes (especially when you have
experience or think outside the scope of the book) you can run into "special
situations".
Example:

Q: What is the BEST answer for blablablablaabl...

A:
a bla
b bla
c bla
d bla

and I go like: e?! (which of course is not provided)

what I mean to say is that when having experience the real correct answer
might not be listed. However the answer fitting into the scope of the book
is. And that can be annoying.

It is just like at school....
Learn a crap load of formulas or learn how to get to those formulas (I
prefer the last). And besides that I always like to understand why something
works that way.

The way I learned this stuff is by reading, testing, reading, testing, etc.
(really touching the buttons and trying things)
Boot camps... I hate them. Why? You don't learn how things work. You only
learn how to pass the exam and that is IMHO wrong! Because after the exam
you still don't know how it works.

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message
news:u4ps5COfGHA.1264@xxxxxxxxxxxxxxxxxxxxxxx
The problem though is the whole MCSE process and the Microsoft Courseware
and what the MCTs teach. You don't get to choose how you get to learn it,
you must learn it with the terms and angles the books push it or you will
run into issues when testing.

IMO, the stuff is mostly crap and doesn't apply well to the real world as
Jorge indirectly points out. It is why so many MCSE's are so woefully
unprepared when they step into a real shop trying to apply their MCSE
skills though they may have been a wizard on the tests and the boot camps.

joe


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm



Jorge de Almeida Pinto [MVP] wrote:
The most important thing for you to remember is not which OU models
exist, but how to create such a model. As you are reading you see several
models exist. IMHO it is better to learn how to create a model than to
learn which models exist.

The OU structure is very depended on several things and those things also
determine the OU structure itself.
The OU structure depends on the following three aspects in the same
order:
(1) delegation of control: the first concept OU structure depends on how
administration is done within a certain organization. For that you need
to know the admin roles, the admin tasks within a role and the locations
of those roles (e.g. in a decentralized administration model). After
retrieving this information by reading documentation or doing interviews
you should be able to create the first concept OU structure

(2) hiding objects: the concept OU structure created in (1) is used as
input for this part. Here you may ask yourself and the organization: "are
there any objects within this OU structure that should not be visible to
certain people". If the answer is yes, you may need to split certain OU
into more OUs and configure those OUs with certain permissions so that
those OUs in those OUs are not visible for administration or even LDAP
queries. If the answer is NO, you leave the OU structure as is and move
on to the next part. To be certain, if something was changed check if the
second concept OU structure still fulfills the requirements set in (1)

(3) applying GPOs for policy enforcement and/or software deployment: the
concept OU structure created in (2) is used as input for this part. Here
you may ask yourself and the organization: "what GPOs are needed to
enforce policies and distribute software?". It could be that within an
organization GPOs are only used for policy enforcement and not for
software deployment as that may be done with SMS or some other tool.
Again, depending on the policies needed you may need to split certain OU
into more OUs so that you can apply the different GPOs to those OUs.
Remember that GPOs can also be used for delegation of control purposes
using the restricted groups feature where you can say (A) which groups
are certain objects a member of (members of groups not enforced) (B)
which members does a certain group have (members of groups enforced)
To be certain, if something was changed check if the third concept OU
structure still fulfills the requirements set in (1) and (2).

(1) and (3) are used very often used. (2) may not be used that commonly
because not everyone needs that.

also see:
http://blogs.dirteam.com/blogs/jorge/archive/2006/05/16/983.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/01/05/369.aspx



.