 Hi, welcome to Deploying Microsoft Exchange Server 2010. My name is Sandra Vitakis and I'll be your instructor. Now, Microsoft Exchange, when I'm in front of a classroom, always brings me back to the day that I heard it first. Now, this, of course, goes back to when I was a novella instructor, we had DOS, advanced DOS, advanced Windows, and we started off with Microsoft Mail. I remember learning Microsoft Mail and thinking really how neat it was, and then someone had asked me, I really hope that you will learn Exchange because this is going to be the next big thing. Now, this, of course, is the initial release of Microsoft Exchange, and I remember tackling it and being absolutely amazed. Well, many, many years have gone by since then, and we're now up to Exchange 2010, and the comparison is unreal because from a very simple mail client where your mail went into a folder and you just checked that folder through an application, through some of what we can do on an enterprise-wide is absolutely amazing. So in this course, I really look forward to not only showing you Exchange, but showing you all the little details of Exchange that will help you manage your email organization. In this chapter, we're going to set a base for Microsoft Exchange Server. That base really involves learning about the network infrastructure before Exchange is even deployed. Now, if you happen to be an active directory administrator, you are going to see a lot of overlap here. However, there's a lot of times some separation in roles where you have an Exchange administrator versus an Active Directory administrator, but when it comes to Exchange, you have to have that base knowledge. So we'll spend some time a little quickly, but time spent on network infrastructure. Network infrastructure, all the services required behind the scenes from DHCP to DNS, and we'll take that right through into Active Directory. Learning about Active Directory, user accounts, what group policy is, because really understanding Active Directory, even if that's not what you do full time, will help you troubleshoot a lot of what's going on with Exchange. Trust relationships, different components, what the schema is. So when we're done with the Active Directory piece and the network infrastructure piece, then we'll go ahead and start learning about Exchange. We'll start off with how to prepare for Exchange installation. We'll go through the different editions and licensing information that you may need, and of course, start introducing the server roles. Exchange server isn't just a simple install, you actually install it, choosing which roles of Exchange will be on each server. So based on that, we'll go through each one of the roles, different deployments from simple to complex, hardware requirements. We'll mention a little bit about Exchange online services. Everything's going up in the cloud these days, so we'll spend some time talking about that cloud. Now, once we're done with all of that, we'll actually go through the installation options. So we have our base of Active Directory, we know what we have to do to prepare Active Directory, we know what we need for hardware and software, and again, those software requirements will allow us to really take our installation and let it run. Let's start with network infrastructure. Network infrastructure means everything that has to be running service-wise in your network before Exchange will even begin to survive. Now, when I say begin to survive, we can't even install it without the proper network infrastructure. So in its simplest form, what you need is you need Active Directory domain services, and of course the infrastructure that supports Active Directory, which is DNS, DHCP, and some form of time sync. So let's talk a little bit about Active Directory first. What is Active Directory? Active Directory is really everything that we have in our network. It's all of our network, all of our objects, all of our object attributes. It's all being described in something called the schema. Well, the schema is just one role or one component of Active Directory. It just happens to be where everything is defined. But in its simplest form, what we think of for Active Directory is where all the user accounts are, all the computer accounts. We have all the security-based information on how we want items to communicate, group policy, which rolls out and deploys. Now, you can't use group policy to deploy an exchange organization. However, group policy does help you because it might be how their email client is actually deployed, meaning the software. Or it might affect who is sitting at what machine. So group policy has a big piece against what people are even gonna load on their desktop. Now, some of the other items I do with group policy is if we're not rolling out items like Microsoft Outlook for an email client, I can use group policy to configure Internet Explorer to make Outlook Web Access a favorite or put it on the favorites bar or maybe it's gonna be their homepage. So it really comes into play to manage the network, but there are components of it that help out considerably with Microsoft Exchange. DNS is, of course, how we solve IP addresses to host names. However, DNS is also how we find these network-based services, where we find our domain controllers, where we find things within our site. So DNS helps out quite a bit with that infrastructure. It's not just IP address to name resolution. Active Directory also has two different topologies. A lot of times you'll hear about a physical topology versus a logical topology. A physical topology is where your sites are. Sites are huge when it comes to Microsoft Exchange because they do affect, within different sites, different physical locations for your organization, how mail is gonna be delivered. So we have our physical topology of sites, but we have our logical topology of really dealing with the domains themselves, the child domains, organizational units where all of the users might actually be. So the logical topology is what we overlay so that we can organize it to make it work the way we need it to work. So let's put some definitions to some terms. When you're looking at Active Directory infrastructure, we have forest domains, child domains, and domain trees. Well, the first thing to cover is forest. You can only have one exchange organization within your forest. Now, a forest is a collection of domains and child domains or domain trees that share a common schema. A schema is really all objects and all object attributes that are available within the network. Now, let's go ahead and put that in English. Object would be a user object, like literally a user that logs in. So we're gonna have a user by the name of Sandra. Now, an object attribute can be anything from first name, last name, password, description, department, all of that if we're talking about basic Active Directory and login, but the attributes get extended, and that's the key word here, when you install Microsoft Exchange so that the attributes now also include email address and mailbox location, and perhaps what is enabled or disabled? Are you going to be able to retrieve your mail through pop or IMAP or how are we gonna handle that? Are you going to be able to use Outlook Anywhere in example? So those are all descriptors of a user account, what can be turned on and off, which happens to be exchange specific. So one of the reasons that we have at one exchange organization per forest is because of the schema, because we're really defining for exchange what those attributes are going to be. So on the domain, the child domain, the domain tree, real simple, a domain really is what we call a security boundary. So in example, let's say this is the absolute first domain that we have. Now this first domain, let's just call it sjb.com. So we've defined it by installing Active Directory on that first machine. We create that domain, we name that domain. It also creates the forest, meaning that's kind of our first part. Now let's say that we need more security boundaries. I want an entire area of the organization dedicated to training. So now you might create a child domain called training.sjb.com. And really what these two share is something called a namespace, which is sjb.com. And they also share something called a trust relationship, we'll get to shortly. So training would be known as a child domain. Now you can name them any way you want. Sometimes they're named based on organization, training, consulting, sales. Sometimes you'll see they're actually named based on geographic preference. So that might be North America versus South America. A lot of times you'll see that it's actually mixed. So maybe this is North America versus South America. And then down here maybe it's training.South America, an example. So all of that is really what we call a domain tree. A domain tree is a collection of domains that share a common namespace. Now, within a forest, you can have domains that do not share a common namespace. So let's say that we created a domain called sanderclassroom.com. So we created it, but we really want it part of our forest or our active directory structure. So you can create it under a different namespace as long as you create it within that forest. And again, that can have its own child domains as well. So again, this isn't an active directory course, but to understand how all of this works, we also have a way to define UNC path. So I can decide that this organization is so complex that I need to condense everything down and I want to condense it for not only login, but for email addressing. So here it comes. I can decide that my new UNC is going to be SC.com for sanderclassroom.com and that's how people are going to log in. So it doesn't match anything we have, but that can be defined as not only A, something that people can log on as, but B, something that we're going to approve for incoming mail. When you look at the topology, remember you have physical and logical. So physical topology says, you know, we can have more than one physical location. So maybe my office is in Portland, Maine and maybe my other office is in Boston. However, regardless of where you physically work, meaning which office, you're all going to log on to sanderclassroom.com. So what happens when you bring sites into an exchange organization, you're going to have exchange servers most likely in both sites. So we have some efficient mail directory and the process of getting email from this site to this site is something that we get to control and configure within exchange itself. So we will talk a lot about hub transport servers and how they work and how they go from site to site, but the whole reason for this site to site has nothing to do with exchange and creating these sites, but those sites actually come from the active directory sites themselves. Now it's also possible to have separate sites or separate domains. So an example in site one, let's have this be the Portland office, maybe in the Portland office I have people who actually work for sanderclassroom.com and training.sanderclassroom.com, and I'll just kind of abbreviate that. So yes, we do have two domains, your child domain and the other domain, it could be two unrelated domains as long as you're all part of the same forest, but again, they're all sitting in the same physical site. So you can mix the topologies because one really has to do with a logical structure of group policy and security and who gets what, and the other one has everything to do with routing, whether it's the actual active directory servers replicating with each other or the routing of email. So again, physical versus logical. So let's define trust relationships. Now you'll see this twice, here we'll just introduce the concept and then in a little bit we'll go back to it, but really for definition a trust relationship allows communications between the machines. Now this is important because if a machine is not trusted by the domain, it won't be able to log on and depending on how you can figure out look, it might mean that someone can't retrieve their mail or even log on to get to their mail. So we have login information from a trusted machine and we access resources that are going to be trusted, again those resources could be network-wide or they could be exchange-based. There's a lot of different types of trusts and really here we're gonna generalize it because it's really more for an active directory class but sometimes exchange organizations do extend outside of our domain. There's ways to talk with maybe a partner network. So that gets a little bit more involved but usually when you start traveling that path you are still dealing with trust relationships with even external organizations. So very simply if I have a domain tree and you will see that this is the top level domain and the two child domains, a transit of trust means if A trusts B and B trusts C, then A automatically trusts C. So a transit of trust means we can move up and down that tree. Well if you have a really complex organization and you wanna go ahead and take this machine and you want it to be able to do something here, then you can create a shortcut trust so that the flow doesn't have to go all the way up and all the way down, it can essentially cut straight across. A forest trust is if you have a branch partner network and you somehow wanna integrate the two exchange organizations and again we're not integrating them as one, we're letting them work together, that's going to be an external trust. And a realm trust is really if you're going to go out and you have a UNIX realm, it's very similar to an external trust, but when again you're starting to trust either a partner network or other networks within your organization.