PowerShell

As Microsoft begins incorporating PowerShell into more and more products, most admins are wondering how to get their feet wet. The way that I’ve been recommending is to stop using cmd: install PowerShell on your desktop and don’t ever launch cmd.exe again. PowerShell has aliases built in so that most of the commands available via cmd work without any changes. Thus, instantly, you’re using PowerShell without actually having to learn anything new. Then, slowly you can start investigating some of the awesome power available in the aptly named PowerShell.

Exchange and SMTP Relay Misinformation

By default SMTP relay is disabled in Exchange 200x.  This of course is a good thing because it prevents Exchange systems exposed to the Internet from being unwittingly used by spammers to “relay” their e-mail to other systems.

Often, organizations have an application that sends alerts or notifications via e-mail so they assume that they have to add an exception to allow that application to send e-mail via the SMTP service on the Exchange system.  This is only partially correct: the exception only needs to be added if the e-mail is being sent to externally hosted addresses.  If the mail is to be delivered only to mailboxes hosted by the organization that the Exchange server is part of, then this e-mail is for local delivery and not relayed.  Thus it is not subject to the relay restrictions in the SMTP service and no exception is needed.

This makes sense, because ultimately, the internal application server is no different than an external SMTP server trying to deliver e-mail.  If the address is valid and local, you would never want Exchange to reject it regardless of the source.

AD Empty Sites

Active Directory sites are considered empty if they do not contain a domain controller. This immediately begs the question: why would anyone want an empty site? The answer is that there are more applications than just Active Directory that are site aware. This, albeit short list, includes DFS, SMS 2003, SCCM 2007, and Exchange 2007. Thus, just because a site does not have a domain controller, does not mean that the boundary defined by the site is not important for another application.

So just how do clients determine which site that they are in? Sites are of course are defined by IP subnets and at the time a client is joined to the domain, it performs a lookup in Active Directory to match its IP address to a site which is then stored in the registry. This information is updated every time a client logins into the network.

Why do some consider empty sites bad? This stems from the mis-perception that clients in an empty site will not be able to choose an optimal domain controller. Clients find domain controllers by looking them up in DNS based upon the site that they are contained in. Active Directory creates DNS records in empty sites for domain controllers according to the topology generated by the KDC. This can also be manually controlled via Group Policy or the registry on specific domain controllers: How to optimize the location of a domain controller or global catalog that resides outside of a client’s site.

Empty sites do need a little extra thought, but they do have a purpose and should not be discarded. For detailed information about how clients find domain controllers, see the Locating Active Directory Servers from the Windows 2000 Resource Kit.