The Swiss Federal Institute of Technology (ETH) just released a pretty interesting e-Learning Course regarding "Security in the Information Age".
I personally think that ir somewhere opens up the IT-Security-Guy's mind:
http://www.isn.ethz.ch/crn/activities/elearning.information-age.cfm
Roger
I received a mail from a blog reader (Jim) who asked:
"Can you provide any insight regarding and tweaks or configuration settings you guys use on your DC builds?"
Sure, I'm happy to do this, so here I am typing happily along, and realized that there is a lot more configuration/tweaking/settings that we use than I should reasonably put into a single blog entry. Instead this will be the first of multiple entries...
So, let's start at the very beginning (it's a very good place to start)... With our standard hardware platforms. All MS IT domain controllers are based on either our "large" or "small" SKU...internally, we call these are DC-E (enterprise) or DC-F (field) platforms.
The DC-E specs are:
The DC-F specs are:
All of our DC's run x64 OS's...well...unless we have some dogfood requirement for 32-bit OS runtime (which we periodically do)...but for all intents and purposes, let's just pretend because we really WANT to run all 64-bit OS's.
Somewhere previously I mentioned that our average DIT size is 10-11GB on disk. The DC-E with 16GB of RAM let's us cache the entire database with room for growth, the DC-F with only 8GB of RAM is usually deployed where we need services, but don't have the load so caching is less of an issue. In that case, the DC-F is significantly cheaper for us.
The recommended practice is to choose a virtual drive assignment and stick to it; commonly, this is drive Q: - so what happens if you want to change to something else, for example, V:
If all applications were equal and followed recommended practice, then simply changing the environment variable %SFT_MNT% on the client would enable you to change the virtual drive at will and no applications would need to be re-sequenced; however, not all applications are equal and this can cause some issues.
Some applications hard code the installation drive in the registry or configuration (INI) files - This means you have several options:-
As with all applications, if you decide to have a different client virtual drive compared to the sequencer then testing will be paramount.
Some customers have reported that update package for KB917013 was being deployed to WSUS clients without having approved the update for installation on their WSUS servers. The original update release, released February 2007 as an optional update, was only applicable on systems which had a version of Windows Desktop Search installed. The recent update Revision 105, had the applicability logic expanded to be applicable to all systems regardless if a prior version of Windows Desktop Search was installed, IF of course, approved in the WSUS Administrative UI or via Administrator-set auto-approval rules.
The initial update would have only been installed if the update had been either auto, or manually approved, and if the applicability criteria was met on the client (that WDS was installed). For some customers, because the original update was approved for install, but because of the previous applicability rules to apply only to clients which had WDS installed, the update was not actually installed.
So what happened with this revision and why did it seemingly deploy itself to all systems in my environment? WSUS by default is set to auto-approve update revisions to minimize administrative overhead and make sure distribution “just works”. Keeping in mind, revisions are only titled as such, when metadata or applicability rules of an update package change, never the binaries. Revisions are also of course only auto-approved via this setting, if the original update is approved.
With the expanded applicability rules, and the WSUS default setting to auto-approve new revisions, it may have appeared as if this update was deployed without approval. The initial version of the update would have had to have been approved, and the “auto-approve revisions” option on (by default) in order for this revision to have also been approved and deployed.
To Recap:
That said, We will be tightening the criterea for Revisions so that auto-approval of revision behaivors are more predictable and of similar scope as the originial approved update, as we appreciate the confusion this behaivor caused.
Thanks as always for your feedback to make our product s and processes work for our customers.
Bobbie Harder
PM, WSUS
Exchange Server 2007 can be installed into an existing Exchange 2000/2003 (hereafter called Exchange 2003, except where there's something particular about Exchange 2000) organization as one step in the migration process. Once Exchange 2007 has been introduced into the Exchange 2003 organization, the organization is considered to be in a co-existence or "Interop" (interoperability) state so long as both versions are present in the Exchange organization.
While in this co-existence mode, Exchange 2003 and Exchange 2007 each have some management behaviors that you should keep in mind. This blog post will detail some of these behaviors.
Mailbox Management
Exchange 2003 mailbox management is done through the Active Directory Users and Computers (ADUC) snap-in extension for Exchange. Exchange 2007 mailbox management is done through the Exchange 2007 Exchange management shell or the Exchange management console GUI. Separately there is no confusion. However, when you're in a co-existence state, both management tools will be present. Although Exchange 2007 will not install the Exchange extensions for ADUC, any remaining Exchange 2003 servers or "admin-only" installations will still have this snap-in available for use.
So which tools to use on which objects? Here's the easy list to remember:
- Exchange 2007 mailboxes must be managed with Exchange 2007 management console or shell.
- Exchange 2007 mailboxes MUST NOT be managed with Exchange 2003 tools. Note that this is not blocked, but mailboxes managed from Exchange 2003 ADUC will not be fully functional.
- Exchange 2003 mailboxes can be edited or removed with Exchange 2007 tools, but cannot be created by Exchange 2007 tools.
- Exchange 2003 mailboxes can be managed with Exchange 2003 tools.
- Both Exchange 2003 and Exchange 2007 mailboxes can be moved (in either direction) with the Exchange 2007 tools. Exchange 2003 move mailbox cannot be used to move mailboxes to or from Exchange 2007 mailbox server.
Recipient Management (contacts, groups, etc)
Since these other recipient objects (contacts, groups, etc) are not tied to a particular server version in the way a mailbox is, these objects can be managed successfully from either side. Because Exchange 2007 tools have knowledge of the full set of Exchange 2007 properties and validation rules, it is recommended to consistently use the Exchange 2007 tools for this recipient management for best results.
The one exception to this rule is Dynamic Distribution Lists (DDL or sometimes called Dynamic Distribution Group, so DDG). Since DDLs created with Exchange 2007 tools store their RecipientFilter in an OPATH format and those created with Exchange 2003 tools store the filter as LDAP, it makes these edits incompatible. Be sure that after you've set a DDL filter through Exchange 2007 you only edit this DDL through Exchange 2007 tools from that point forward.
Global Objects (Address lists, EmailAddressPolicy, etc)
There are also a number of global configuration objects shared between Exchange 2003 and Exchange 2007 when running in a co-existence state. Examples of these objects are: Address Lists, Email Address Policies, Offline Address Book, etc.
These global objects generally follow the pattern that if they are created in Exchange 2003, they can be fully edited only in Exchange 2003 until they are upgraded to Exchange 2007 version. Once upgraded to Exchange 2007 format (and for objects created in Exchange 2007), they can no longer be edited by Exchange 2003 (and Exchange 2003 system manager will actively block you making edits after the object is upgraded).
Also, as mentioned in the "Goodbye RUS" post, you should not configure an Exchange 2007 server to serve as the "Exchange Server" for a Recipient Update Service. Doing so will cause that RUS to cease to function.
Other Miscellaneous Objects
In Exchange 2003 system manager there are a number of other objects that are visible. For instance, the Exchange 2007 administrative and routing groups (and their embedded GUID) are visible to Exchange 2003 while the entire AG/RG concept is hidden in Exchange 2007.
Similarly, the Exchange 2007 server object (and storage groups, databases, protocols, etc) are also visible in Exchange 2003. Where possible, these Exchange 2007 objects are "blocked" from editing through the Exchange 2003 tools. In all cases, you should not use the Exchange 2003 tools to manage Exchange 2007 servers or Exchange 2007 versioned objects.
Some items in the Exchange 2003 are not hidden or blocked, but are simply non-functional. Deprecated items like monitoring administration and Exchange 2003 queue viewer remain visible and will produce an error connecting to the interface if you attempt to access them.
Finally, some items in the Exchange 2003 ESM will remain the appropriate GUI way to manage certain objects until replacement GUI is established in Exchange 2007. Two such items that fit this mold are the Public Folder GUI (which will remain functional and supported, so long as an Exchange 2003 server is the targeted public folder store) and the Address/Details template customization GUI. In both of these cases, the Exchange 2003 GUI is anticipated to be replaced by updated Exchange 2007 GUI at some point in the future.
Exchange 2000 and object blocking
Exchange 2003 ESM automatically includes support for "blocking" edits against Exchange 2007 objects, as described above. Exchange 2000, however, requires a post-SP3 hotfix to provide this same behavior. Although Exchange 2000 SP3 is the prereq'd version required by Exchange 2007 setup, you must make sure that all Exchange 2000 servers and Exchange 2000 admin-tools-only consoles are updated with both Exchange 2000 SP3 and the 6603+ roll-up hotfix – KB.870540 (also known as the August 2004 roll-up hotfix). Note that if this hotfix is not present on an Exchange 2000 admin console used to manage your Exchange 2007 objects, it is possible that Exchange 2007 objects can be modified incorrectly from this legacy console.