Microsoft's official enterprise support blog for AD DS and more
Hello, Sean here. I’m a Directory Services engineer with Enterprise Platforms Support in Charlotte. Today, I’d like to talk about the inner workings of Advanced Group Policy Management (AGPM). Let’s begin by discovering what occurs behind the scenes when you take control of a Production GPO using AGPM.
The term “Production GPO” is used frequently in AGPM documentation to describe an existing GPO in Active Directory and differentiate between it and the copy that AGPM stores in the Archive to allow for “Offline Editing”.
For those new to AGPM, it provides many features to help you better manage Group Policy Objects in your environment. Role-based administration allows you to delegate certain actions to users, even those that may not be administrators. The four built-in roles are Reviewer, Editor, Approver and Administrator. Change-request approval helps to avoid unexpected and unapproved modifications to production GPOs. AGPM also provides the ability to edit GPOs offline, allowing for review and approval of the changes before committing them to production. Furthermore, version tracking of GPO changes, the ability to audit/compare versions and the rollback feature can help you recover from GPO changes that need to be revised. The Overview of Advanced Group Policy Management white paper (Link) has information about these features and more.
Environment Overview:
The environment has three computers: a domain controller, a member server, and a client.
The AGPM server and client computers are members in the contoso.com domain. This scenario uses the 64-bit version of AGPM for server and client installations, but a 32-bit version is available as well. The AGPM server and client installs were done following the Step-by-Step Guide (Link). This document is also included on the MDOP disk (..\Documents\4.0\AGPM_40_Step-by-Step_Guide.pdf).
Tools Overview:
The following tools will be used to gather data during this exercise:
Prologue:
Before we begin, it’s important to understand how AGPM is able to delegate management of GPOs to non-Administrators. Delegation of the various AGPM roles is done within AGPM itself. All operations performed by AGPM in the domain are handled by the AGPM service account. During the AGPM server installation, you specify what account you wish to use as the AGPM service account. This single account is granted the permissions to create, delete and manage GPOs in the domain. When we start GPMC as a user who has delegated permissions within AGPM, even if the user account has no rights to manage GPOs by itself, AGPM instructs the service account to perform the actions on the user’s behalf.
When performing data collection on multiple systems like this, it’s important to understand how each component works, and under what security context it’s working. For this task, I’m logged into CONW71 with my AGPM Administrator account (agpmadmin). The changes I make through the AGPM console on CONW71 are commands sent through GPMC.msc as the user agpmadmin. Even though I request to change the status of a GPO that is located on a domain controller, the commands sent from CONW71 go to the AGPM service running on CONAGPM. On CONAGPM, the AGPM service receives those commands and evaluates what permissions the submitting user account has been granted.
Based on the role of the user submitting the commands to the AGPM service, the action will be allowed or disallowed. If the user has the appropriate permissions, the AGPM service builds the request to send to the domain controller and forwards it, not as the user who initiated the requests, but as the AGPM Service account. Since the AGPM service account is being used for the request sent to the domain controller, access is based on the permissions assigned to the AGPM service account.
Getting Started:
First, we’ll log into CONDC1 and create a few Organizational Units (OU) named “Development”, “HR” and “Sales”. By right-clicking on the OUs and selecting “Create a GPO in this domain, and Link it here”, we will create the new GPOs that will automatically be linked to their respective OUs. CONDC1 doesn’t have the AGPM server or client installed, so we will use the vanilla Group Policy Management Console (GPMC.msc). For the sake of today’s blog post, we’ll only be working with the “Dev Client Settings” GPO. Let’s add a few drive mapping GP Preference settings, just to make it seem a bit more authentic. Before we do anything further to the GPO, let’s make note of a few key details regarding the GPO.
Second, we want to get each of our data collection tools ready to capture data. Logging options will be configured for GPMC and AGPM. Active Directory Object Auditing will be enabled, and our GPO will have auditing configured to report any attempted change, successful or not. Network Monitor and Process Monitor will be started and tracing on all three computers right before we take control of the production GPO.
Next, we’re ready to take control of the GPO using the AGPM client installed on CONW71. Computers that have the AGPM client installed have a new “Change Control” entry within GPMC. This is where we will perform most of the functions that brought us to install AGPM in the first place. On the “Uncontrolled” tab, we see a list of GPOs in the domain that are not currently controlled by AGPM. Let’s right-click on the “Dev Client Settings” GPO, and bring up a context menu where we select the “Control” option.
If we hold the delegated role of AGPM Admin or Approver, we’ll be prompted to add a comment for this operation. Without Admin or Approver, we’ll be asked to fill out a request form that will be emailed to the AGPM Approvers first. It’s always a good idea to comment with something meaningful, explaining why we’re taking ownership of this GPO. It’s not always obvious why changes were made to a GPO, and the comment is our chance to inform others of the reasons behind our action. If your organization has change control procedures, it would be an excellent place to link the action to the official change request identifier.
Assuming we have the permissions to take control of a production GPO, when we add our comment and click “Ok”, we will see a progress window appear. It will update itself with the progress it’s making on our request. It should report whether the operation was successful or not, and if not it should give us some additional information regarding the problem(s) it ran into.
Simple enough on the front end, but what exactly is taking place behind the scenes while we made those flew clicks? Let’s take a look…
The AGPM Client
Network Monitor on the AGPM Client shows some TCP chatter back and forth between an ephemeral port on the AGPM client, and TCP Port 4600 on the AGPM server. TCP 4600 is the default port when installing the AGPM Server component, but you can change that during the install or after (Link) if you prefer. There is no communication between the AGPM client and the domain controller other than ARP traffic. The process making the calls to the AGPM server is MMC.exe.
Process Monitor on the AGPM Client is similarly sparse on information. MMC.exe accesses the registry and file system briefly as it builds the request to send to the AGPM server, and writes to the agpm.log file under the profile of the logged on user.
GPMC logging (gpmgmt.log) seems to generate many entries, but there were none generated on the AGPM Client during the test.
AGPM logging on the client shows a number of actions being taken between the AGPM Client and AGPM Server. The control operation appears between two [Info] entries, and shows the various functions being called by the AGPM client to process and report the results from the operation to the user.
The AGPM Server
Moving to the AGPM Server, we can see a difference in behavior from nearly every data point.
The network capture from the AGPM Server shows the TCP communication back and forth with the AGPM Client followed by TCP and LDAP packets between the AGPM Server and the Domain Controller. Once the commands have been received from the AGPM Client, the AGPM Server initiates the requested actions with the Domain Controller. The request to change the GPC and its contents comes in the form of SMB SetInfo Requests.
If we drill down into the packet info, into the SetInfo Request… we’ll see the modified object:
And further down, the DACL changes:
The highlighted SID is for the AGPM Service account in our domain. We can get the user account SID for the AGPM service account by looking up the objectSID attribute of that user account within ADSIEdit.msc. 0x001f01ff is the equivalent of Full Control. Notice, the owner is still set to S-1-5-32-544 (Built-In/Administrators). This is the case for every file and folder within the GPT except for the top level folder named after the GPO’s GUID. Here we see the AGPM Service account’s SID again.
After the AGPM Service account has permissions, you can see it start to query the domain controller via LDAP and SMB2, copying over the GPO to the AGPM server. This is the AGPM server creating a copy of the GPO in the Archive you created during installation of the AGPM Server.
Process Monitor on the AGPM Server is very busy. First, the service checks for the Archive path, and reads through the gpostate.xml file, checking to see if it already knows about this GPO. The gpostate.xml file contains a historic view of GPOs known to AGPM. We see some LDAP communication between the AGPM server and the Domain Controller that corresponds to the AGPM server modifying permissions on the portion of the GPO that resides in Active Directory. This is followed by the AGPM service exploring the entire folder structure of the GPO’s SYSVOL component, modifying the DACL and Owner information to include the AGPM service account.
In order to provide the ability to edit GPOs offline, AGPM makes use of the Archive to store a copy of each GPO it controls. The Process Monitor capture from the AGPM Server gives us a very good look at what’s going on between SYSVOL and the archive.
We see it start to dig into the Group Policy Template for the GPO we’re taking control of, reading the information from the folders and files beneath it. In the next image, we see the AGPM service query the registry for the location of the Archive.
We also see below that it reads from a Manifest.xml file. This is a hidden file that has some basic information about every GPO in the Archive. Things like the GPOs production GUID, the domain and domain GUID, as well as the AGPM-assigned GUID.
After this, the AGPM service starts to create a folder structure within the Archive for the GPO. What’s interesting here is, closer scrutiny reveals an uncanny resemblance to a standard GPO backup routine. If you’ve ever backed up a GPO using GPMC, you’ll recognize the files and folder structure created by AGPM when it adds a GPO to its archive.
Notice the GUID in the Archive path. AGPM creates its own unique identifier for the archived copy of the GPO. Process Monitor shows the AGPM service going back and forth between SYSVOL, reading info and writing it into the Archive. The AGPM service pulls the settings from the GPO and creates a gpreport.xml file with that information in it. GPReport.xml also has the following information within it:
Two other files in the archived GPO’s folder are Backup.xml and bkupInfo.xml (Hidden). Backup.xml contains the following information:
BkupInfo.xml is essentially an excerpt directly from Manifest.xml of the info that pertains to this GPO.
AGPM logging on the AGPM server doesn’t generate many entries during the control operation. It shows the incoming message, identifies the Client/Server SIDs (The user account SIDs of the user initiating the action on the AGPM Client, and the AGPM service account being used by the AGPM Server), and calls the appropriate functions. The control operation has the AGPM Server sending requests to check the GPO’s security (doGpoLevelAccessCheck()) and then take control of the GPO (ControLGPO()).
GPMC logging on the AGPM Server gives us a wealth of information. Without much delay, you see the GPMC log record a LDAP bind and permissions being modified on the GPO objects within Active Directory.
The next thing you’ll notice in the GPMC logging on the AGPM Serer is reference to Backup related functions being called. Remember seeing the AGPM server accessing the Group Policy Template and Container seen in other data collections? When the GPO is copied to the AGPM Archive, this is essentially a GPO backup, very much like the one you can perform in GPMC.msc. The remainder of the GPMC log was dedicated to covering the backup processes.
The Domain Controller
This is the last stop in our data analysis. The network capture shows the traffic from the AGPM Server. Process Monitor, however is a bit different. Where the AGPM Server had a lot of entries specific to our operation to control the GPO, all of the information in Process Monitor on the Domain Controller shows up as reads/writes to the Active Directory Database (NTDS.DIT). Process Monitor does not allow us to see what was being read/written, so they are fairly useless for really seeing what’s going on.
The Security log has generated many events, just in the short time it took to take control of this GPO. We can see the AGPM service account connect and read various attributes of the Group Policy Container from Active Directory. We’ll also see a single event for the actual modification of the Group Policy Container (GPC) replacing the current nTSecurityDescriptor information with one containing permissions for the AGPM Service Account.
The Object Name value in the event data corresponds to the objectGUID of the GPO’s container object within Active Directory.
Since AGPM nor GPMC was utilized on the Domain Controller, there are no corresponding logs to review from those tools.
In Closing
We’ve pulled the curtain away from a very simple procedure of taking ownership of a production GPO, reviewing it from different perspectives using different tools, and found it’s a very simple task that is broken up into a few common subtasks.
Once the GPO is controlled by AGPM and backed up to the Archive, a number of other tasks can be performed on it, which we will cover in depth in future blog posts.
Complete series
http://blogs.technet.com/b/askds/archive/2011/01/31/agpm-production-gpos-under-the-hood.aspxhttp://blogs.technet.com/b/askds/archive/2011/04/04/agpm-operations-under-the-hood-part-2-check-out.aspxhttp://blogs.technet.com/b/askds/archive/2011/04/11/agpm-operations-under-the-hood-part-3-check-in.aspxhttp://blogs.technet.com/b/askds/archive/2011/04/26/agpm-operations-under-the-hood-part-4-import-and-export.aspx
Sean “right angle noggin” Wright
Hello, Dave here. Today I discuss the Access Based Enumeration (ABE) feature in Windows Server and how it may be implemented with Distributed File System Namespaces (DFSN).
First you may ask, "What is ABE, and why would I want to utilize it?" By default, all folders and files will be listed in a folder, even if the browsing user doesn't have permissions to them. For example, three users (Alice, Bob, and Cindy) have folders under a share on file server ‘FS1’.
Each user's folder has permissions such that only the single user has access (icacls.exe output below):
\\fs1\share\Alice CONTOSO\Alice:(OI)(CI)F \\fs1\share\Bob CONTOSO\bob:(OI)(CI)R \\fs1\share\Cindy CONTOSO\Cindy:(OI)(CI)R
The following is what user “Bob” observes when browsing the UNC path \\fs1\share:
If a user attempts to open another user's folder or file within that folder, they will be met with an error as they do not have sufficient permissions. Administrators may not desire this user experience, as it may generate helpdesk calls or confuse users.
ABE is Windows Server feature which causes the server to display only the files and folders that a user has permissions to access. Once ABE is enabled on the share mentioned above, users will only see those folders for which they have access. Below is Bob's view of the share's contents, now with ABE enabled:
ABE is enabled for non-DFS shares via the "Share and Storage Management" snap-in. You may be asking if this feature may be utilized by DFS Namespaces as well. Yes it can!
ABE in DFSN has matured considerably since its original implementation in Windows Server 2003. Back then, you had to install a separate add-on component to expose the necessary UI to configure ABE on a shared folder. Then, you had to follow KB article 907458 in order to make it functional within a DFS namespace. Further complications arose from having to utilize cacls.exe on each namespace server to set link permissions and having to repeat the operation should the namespace be modified in various ways. To say the least, there was significant management overhead.
Fortunately, Windows Server 2008 and 2008 R2 supports ABE in DFSN natively. It may be utilized on a domain-based or standalone namespace such that users will only see DFSN folders for which they have permissions. NOTE: ABE requires the namespace to be in "Windows Server 2008 Mode". If you have existing namespaces that are in "Windows 2000 Server mode" (view the properties of a namespace in the DFS Management snap-in), you will need to convert them to 2008 mode. To do so, please follow the information available here.
As an example, the namespace “ns1” was created and contains DFSN folders for the three user folders discussed previously.
The DFSN folder “Bob” is configured with the target \\fs1\share\bob, as seen below:
By default ABE is not enabled on the namespace, and users are able to see all DFS folders within it. When Bob browses the namespace via the path \\contoso.com\ns1, he will see the three DFS folders defined above: Alice, Bob, and Cindy. By enabling ABE on the namespace, the DFSN service of all namespace servers will automatically enable ABE on their local namespace share and enforce the configured permissions of reparse folders automatically. You will not be burdened with having to run cacls.exe manually on each namespace server.
The commands utilized to enable ABE and set the required permissions are as follows:
dfsutil property abde enable \\contoso.com\ns1 dfsutil property acl grant \\contoso.com\ns1\alice contoso\alice:F protect dfsutil property acl grant \\contoso.com\ns1\bob contoso\bob:F protect dfsutil property acl grant \\contoso.com\ns1\cindy contoso\cindy:F protect
Note: The 'protect' parameter is important as the reparse folders underneath the namespace shared folder will inherit permissions by default and typically not restrict access to the DFSN folders. Also, the “abde” parameter was changed to “abe” in the 2008 R2 and Windows 7 version of dfsutil.
With a Windows 7 client or a 2008 R2 server running RSAT, enabling ABE and setting permissions may be directly performed via the DFS Management MMC. Simply open the properties of a specific DFS folder in the namespace and click the ‘advanced’ tab:
Bob would have the following view of the “NS1” namespace after ABE is enabled and appropriate permissions are set:
In the end, the permissions configured within the namespace ultimately end up on the special reparse folders found within the namespace server's share. It is the enumeration of these reparse folders which dictates if a DFSN folder is observable by a user as they browse through the namespace.
One final note: some DFSN administrators may wish to leverage ABE with a mixture of Windows Server 2003 R2 and 2008/2008 R2 namespace servers using the process detailed in KB 907458. Although possible, you must first deploy a hotfix to any Windows Server 2008 SP2 or 2008 R2 RTM/SP1 namespace servers to prevent the loss of the modified reparse folder permissions. Details about the update are available in KB 2464365.
I hope the information is helpful as you consider implementation of ABE on a DFS namespace. Happy DFSN'ing!
Dave “Honest ABE” Fisher
Ned here. The Windows Server division is looking for your feedback. A snippet from their post:
From our research we have identified 5 areas where our customers have expressed increased concerns:
Enabling an increasingly mobile workforce Working within the constraints of tightening IT budgets Disaster recovery and data backup planning Providing secure and highly available server operating systems Reducing hardware costs and providing more, easily managed, services We want to help you solve these challenges, but first we want to know if you agree with our initial findings. Over the next several months we will be collecting your feedback and proposing solutions to help solve these challenges. We will also highlight other ideas and solutions that are geared towards helping those managing Branch and Mid-Market IT infrastructures.
We want to help you solve these challenges, but first we want to know if you agree with our initial findings. Over the next several months we will be collecting your feedback and proposing solutions to help solve these challenges. We will also highlight other ideas and solutions that are geared towards helping those managing Branch and Mid-Market IT infrastructures.
Get over there and tell them your field experiences:
Need Feedback on Microsoft Technologies for Branch and Mid-Market IT
If you don’t give them info, you don’t get to complain. :)
- Ned “go Bears!” Pyle
Hi folks, Ned here again with your questions and our answers. This is a pretty long one; looks like everyone is back from vacation, winter storms, and hiding from the boss. Today we talk Kerberos, KCC, SPNs, PKI, USN journaling, DFSR, auditing, NDES, PowerShell, SIDs, RIDs, DFSN, and other random goo.
Rawk!
Is NIC teaming recommended on domain controllers?
It’s a sticky question – MS does not make a NIC teaming solution, so you are at the mercy of 3rd party vendor software and if there are any issues, we cannot help other than to break the team. So the question you need to answer is “do you trust your NIC vendor support?”
Generally speaking, we are not huge fans of NIC teaming, as we see customers having frequent driver issues and because a DC probably doesn’t need it. If clients are completely consuming 1Gbit or 10Gbit network interfaces, the DC is probably being overloaded with requests. Doubling that network would make things worse; it’s better to add more DCs. And if the DC is also running Exchange, file server, SQL, etc. you are probably talking about an environment without many users or clients.
A failover NIC solution is probably a better option if your vendor supports it. Meaning that the second NIC is only used if the first one burns out and dies, all on the same network.
We used to manually create SPNs with IP addresses to allow Kerberos without network name resolution. This worked in Windows XP and 2003 but stopped working in later operating systems. Is this expected?
Yes it is. Starting in Windows Vista and forever more, the OS examines the format of the SPN being requested and if it is only an IP address, Kerberos is not even attempted. There’s no way to override this behavior. If I look at it in practical terms, having manually set an IP Address for SPN:
Then I actually try mapping a driver here with an IP address (which would have worked in XP in this scenario):
No tickets were cached above. And in the network capture below, it’s clear that I am using NTLM:
This is why in this previous post – see the “I want to create a startup script via GPO” and “NTLM is not allowed for computer-to-computer communication” sections – I highly discouraged customers from this sort of hacking. What I didn’t realize when I wrote the old post was that I now have the power to control the future with my mind.
Actual MRI of my head, proving that I have an orange (i.e. “futurasmic”) brain
I see that the DFSR staging folder can be moved, but can the Conflict and Deleted (\dfsrprivate\conflictanddeleted) folder be relocated? If so, how?
It cannot be moved or renamed – this was once planned (and there is even an AD attribute that makes one think the location could be specified) but it never happened in the service code. Regardless of what you put in that attribute, DFSR ignores it and creates a C&D folder at the default location.
For example, here I specified a completely different C&D path using ADSIEDIT.MSC before DFSR even created the folder. Once I started the DFSR service, it ignored my setting and created the conflict folder with defaults:
We are trying to find the best way to issue Active Directory "User" certificates to iPhones and iPads, so these users can authenticate to our third party VPN appliance using their "user" certificate. We were thinking that MS NDES could help up with this. Everything I have read says that NDES is used for non domain "computer or device" enrollment.
[From Rob Greene, author of previous post iPad / iPhone Certificate Issuance]
Just because the certificate template that is used by NDES must be of type computer does not mean you cannot build a SCEP protocol message to the NDES Server for use by a user account on the iPhone in question.
Keep in mind that the SCEP protocol was designed by Cisco for their network appliances to be able to enroll for certificates online. Also understand what NDES means - Network Device Enrollment Service.
Realistically there is no reason why you cannot enroll for a certificate via SCEP interface with NDES and have a user account using the issued certificate. However, NDES is code to specifically only allow for enrollment of computer based certificate templates. If you put a user based template name in the registry for it to issue, it will fail with a not –so-easily deciphered message.
That said, keep in mind that the subject or Subject Alternative Name field identifies the user of the certificate not the template.
So what you could do is:
Now you have a certificate with the EKU of Client Authentication and a subject / SAN of the user account, I don’t see why you could not use that for what you need. Not that I have tested this or can test this, mind you…
Is there a “proper” USN Journal setting versus replicated data sizes, etc. on the respective volumes housing DFSR data? I've come across USN journal wrap issues (that properly self heal ... and then occur again a month or so later). I’m hoping to know a happy medium on USN journal sizing versus size of volume or data that resides on that volume.
I did a quick bit of research - in the history of all MS DFSR support cases, it was necessary to increase the USN journal size for five customers – not exactly a constant need. Our recommendation is not to alter it unless you get multiple 2202 events that can’t be fixed any other way:
Event ID=2202 Severity=Warning The DFS Replication service has detected an NTFS change journal wrap on volume %2. A journal wrap can occur for the following reasons: 1.The USN journal on the volume has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal. 2.The DFS Replication service was not running on this computer for an extended period of time. 3.The DFS Replication service could not keep up with the rate of file changes on the volume. The service has automatically initiated the journal wrap recovery process. Additional Information: Volume: %1
Event ID=2202 Severity=Warning The DFS Replication service has detected an NTFS change journal wrap on volume %2. A journal wrap can occur for the following reasons: 1.The USN journal on the volume has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal. 2.The DFS Replication service was not running on this computer for an extended period of time. 3.The DFS Replication service could not keep up with the rate of file changes on the volume. The service has automatically initiated the journal wrap recovery process.
Additional Information: Volume: %1
Since you are getting multiple 2202 occurrences, I would recommend first figuring out why you are getting the journal wraps. The three reasons listed in the event need to be considered – the first two are avoidable (fix your disk or controller and stop turning the service off) and should be handled without a need to alter the USN journal.
The third one may mean you are not using DFSR as recommended, but that may be unavoidable. In that case, set the USN size value to 1GB and validate that the issue stops occurring. We have no real formula here (remember, only five customers ever), but if you cannot spare another 512MB on the drive you have much more important problems to consider around disk capacity. If still not enough, revisit if DFSR is the right solution for you – the amount of changes occurring would have to be so incredibly rapid that I doubt DFSR could ever realistically keep up and converge. And make sure that nothing else is updating all the files outside of the journal on that drive – there is only one journal and it contains entries for all files, even the ones not being replicated!
Just to answer the inevitable question: you use WMI to increase the USN journal size.
On Win2003 R2 only:
1. Determine the volume in question (USN journals are volume specific) and the GUID for that volume by running the following:
WMIC.EXE /namespace:\\root\Microsoftdfs path DfsrVolumeInfo get VolumePath WMIC.EXE /namespace:\\root\Microsoftdfs path DfsrVolumeInfo get VolumeGUID
This will return (for example:)
VolumePath \\.\C: \\.\E:
VolumeGuid 4649C7A1-82D5-11DA-922B-806E6F6E6963 D1EB0B66-9403-11DA-B12E-0003FFD1390B
2a. Raise the USN Journal Size (for one particular volume):
WMIC /namespace:\\root\microsoftdfs path dfsrvolumeconfig.VolumeGuid="%GUID%" set minntfsjournalsizeinmb=%MB SIZE%
where you replace '%GUID%' with the volume GUID and '%MB SIZE%' with a larger USN size in MB. For example:
WMIC /namespace:\\root\microsoftdfs path dfsrvolumeconfig.VolumeGuid="D1EB0B66-9403-11DA-B12E-0003FFD1390B" set minntfsjournalsizeinmb=1024
This will return 'Property Update Successful' for that GUID.
2B. Raise the USN Journal Size (for all volumes)
WMIC /namespace:\\root\microsoftdfs path dfsrvolumeconfig set minntfsjournalsizeinmb=%MB SIZE%
This will return 'Property Update Successful' for ALL the volumes.
3. Restart server for new journal size to take effect in NTFS.
Update 4/15/2011 - On Win2008 or later:
1. Open Windows Explorer.2. In Tools | Folder Options | View - uncheck 'Hide protected operating system files'. 3. Navigate to each drive's 'system volume information\dfsr\config' folder (you will need to add 'Administrators, Full Control' to prevent access denied error). 4. In Notepad, open the 'Volume_%GUID%.xml' file for each volume you want to increase. 5. There will be a set of tags that look like this: <MinNtfsJournalSizeInMb>512</MinNtfsJournalSizeInMb> 6. Stop the DFSR service. 6. Change '512' to the new increased value. 7. Close and save that file, and repeat for any other volumes you want to up the journal size on. 8. Start the DFSR service back up.
There is a list of DFS Namespace events for Server 2000 at http://support.microsoft.com/kb/315919. I was wondering if there is a similar list of Windows 2008 DFS Event Log Messages?
That event logging system in KB315919 exists only in Win2000 – Win2003 and later OSs don’t have it anymore. That KB is a bit misleading also: these events will never write unless you enable them through registry settings.
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\MicroSoft\Windows NT\CurrentVersion\Diagnostics Value name: RunDiagnosticLoggingDfs Value type: REG_DWORD Value data: 0 (default: no logging), 2 (verbose logging) Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs Value name: DfsSvcVerbose Value type: REG_DWORD Value data: Any one of the below three values: 0 (no debug output) 1 standard debug output 0x80000000 (standard debug output plus additional Dfs volume call info) Value name: IDfsVolInfoLevel Value type: REG_DWORD Value data: Any combination of the following 3 flags: 0x00000001 Error 0x00000002 Warning 0x00000004 Trace
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\MicroSoft\Windows NT\CurrentVersion\Diagnostics Value name: RunDiagnosticLoggingDfs Value type: REG_DWORD Value data: 0 (default: no logging), 2 (verbose logging)
Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs Value name: DfsSvcVerbose Value type: REG_DWORD Value data: Any one of the below three values: 0 (no debug output) 1 standard debug output 0x80000000 (standard debug output plus additional Dfs volume call info)
Value name: IDfsVolInfoLevel Value type: REG_DWORD Value data: Any combination of the following 3 flags: 0x00000001 Error 0x00000002 Warning 0x00000004 Trace
Dave and I scratched our heads and in our personal history of supporting DFSN, neither of us recalled ever turning this on or using those events for anything useful. Not that it matters now, Windows 2000 is as dead as fried chicken.
We currently have inherited auditing settings on a lot of files and folders that live on our two main DFSR servers. The short story is that before the migration to DFSR, the audit settings were apparently added by someone to the majority of the files/folders. This was replicated by DFSR and now is set on both servers. Thankfully we do not have any audit policies turned on for those servers currently.
That is where the question comes in: there may be a time in the relatively near future that we will want to enable some auditing for a subset of files/folders. Any suggestions on how we could remove a lot of the audit entries on these servers, without forcing nearly every file to get processed by DFSR?
Nope, it’s going to cause an unavoidable backlog as DFSR reconciles all the security changes you just made – the audit security is part of the file just like the discretionary security. Don’t do that until you have a nice big change control window open. Maybe just do some folders at a time.
In the future, using Global Object Access Auditing would be an option (if you have Win2008 R2 on all DFSR servers). Since it is all derived by LSA and not directly stamped, DFSR won’t replicated the file – the files are never actually changed. It’s slick:
http://technet.microsoft.com/en-us/library/dd772630(WS.10).aspx
In theory, you could get rid of the auditing in place currently currently and just use GOAA someday when you need it. It’s the future of file auditing, in my opinion; using direct SACLs on files should be discouraged forever more.
Does the SID for an object have to be unique across the entire forest? It is pretty clear from existing documentation that the SID does have to be unique within a domain because of the way the RID Master distributes RID pools to the DCs. Does the RID Master in the Forest Root domain actually keep track of all the unique base SIDs of all domains to ensure that there is no accidental duplication of the unique base domain SIDs?
A SID will be unique within a forest, as each domain has a unique base SID that combines with a RID. That’s why there’s a RID master per domain. There is no reasonable way for the domain SIDs to ever be duplicated by Windows, although I have seen some third party products that made it happen. All hell broke loose, we don’t plan for the impossible. :) Even if you use ADMT to migrate users with SID History within a forest, it will not be duplicated as the migration will always destroy the old user when it is “moved”.
The RID Masters don’t talk to each other within the forest (any more than they would between different forests, where a duplicate SID would cause just as many problems when you tried to create a trust). The base SID is a random 48 bit number, so there is no reasonable way it could be duplicated by accident in the same environment. It comes down to us relying on the odds of two domains that know of each other ending up with the same SID through pure random chance – highly unlikely math.
You’ll also find no mention of inter-RID master needs or error messages communication here:
http://msdn.microsoft.com/en-us/library/cc223751(PROT.13).aspx http://technet.microsoft.com/en-us/library/cc756394(WS.10).aspx
I have this message in a health report:
“A USN journal loss occurred 2 times in the past 7 days on E:. DFS Replication monitors the USN journal to detect changes made to the replicated folder. Although DFS Replication automatically recovers from this problem, replication stops temporarily for replicated folders stored on this volume. Repeated journal loss usually indicates disk issues. Event ID: 2204”
Is this how the health report indicates a journal wrap or can I take “loss” literally ?
Ouch. That’s not a wrap, the journal was deleted or irrevocably damaged. I have never actually seen that event in the field, only in a test lab where I deleted my journal intentionally (using the nasty command: FSUTIL.EXE USN DELETEJOURNAL). I would suspect either a failing disk or 3rd party disk management software. It’s CHKDSK and disk diagnostic time for you.
The net recovery process is similar to a wrap for event 2204 ; the journal gets recreated, then repopulated like a wrap recovery (it uses the same code). You get event 2206 to know that it’s fixed.
How come there is no “Set-SPN” cmdlet in AD PowerShell?
Ahh, but there is… sort of. We hide service principal name maintenance off in the Set-ADUser, Set-ADComputer, and Set-ADServiceAccount cmdlets.
-ServicePrincipalNames <hashtable> Specifies the service principal names for the account. This parameter sets the ServicePrincipalNames property of the account. The LDAP display name (ldapDisplayName) for this property is servicePrincipalName. This parameter uses the following syntax to add remove, replace or clear service principal name values. Syntax: To add values: -ServicePrincipalNames @{Add=value1,value2,...} To remove values: -ServicePrincipalNames @{Remove=value3,value4,...} To replace values: -ServicePrincipalNames @{Replace=value1,value2,...} To clear all values: -ServicePrincipalNames $null You can specify more than one change by using a list separated by semicolons. For example, use the following syntax to add and remove service principal names. @{Add=value1,value2,...};@{Remove=value3,value4,...} The operators will be applied in the following sequence: ..Remove ..Add ..Replace The following example shows how to add and remove service principal names. -ServicePrincipalNames-@{Add="SQLservice\accounting.corp.contoso.com:1456"};{Remove="SQLservice\finance.corp. contoso.com:1456"}
-ServicePrincipalNames <hashtable> Specifies the service principal names for the account. This parameter sets the ServicePrincipalNames property of the account. The LDAP display name (ldapDisplayName) for this property is servicePrincipalName. This parameter uses the following syntax to add remove, replace or clear service principal name values. Syntax: To add values: -ServicePrincipalNames @{Add=value1,value2,...} To remove values: -ServicePrincipalNames @{Remove=value3,value4,...} To replace values: -ServicePrincipalNames @{Replace=value1,value2,...} To clear all values: -ServicePrincipalNames $null
You can specify more than one change by using a list separated by semicolons. For example, use the following syntax to add and remove service principal names. @{Add=value1,value2,...};@{Remove=value3,value4,...}
The operators will be applied in the following sequence: ..Remove ..Add ..Replace
The following example shows how to add and remove service principal names. -ServicePrincipalNames-@{Add="SQLservice\accounting.corp.contoso.com:1456"};{Remove="SQLservice\finance.corp. contoso.com:1456"}
We do not have any special handling to retrieve SPNs using Get-AdComputer or Get-Aduser (nor any other attributes – they treat all as generic properties). For example:
get-adcomputer name –properties serviceprincipalnames | select-object –expand serviceprincipalnames
I used select-object –expand because when you get a really long returned list, PowerShell likes to start truncating the readable output. Also, when I don’t know which cmdlets support which things, I sometimes cheat use educated guesses:
I have posted a TechNet forum question around the frequency of KCC nomination and rebuilding and I was hoping you could reply to it.
“…He had made an update to the Active Directory Schema and as a safety-net had switched off one of our domain controllers whilst he did it. The DC (2008 R2) that was switched off was at the time acting as the automatically determined bridgehead server for the site. Obviously the next thing that has to happen is for the KCC to run, discover the bridgehead server is still offline and re-nominate. My colleague thinks that this re-nomination should take upto 2 hours to happen. However all the documentation I can find suggests that this should be every 15 minutes. His argument is that it is a process of sampling, that it realises the problem every 15 minutes but can take upto 2 hours to actually action the change of bridgehead. Can anyone tell me which of us is right please and if we could have a problem?”
“…He had made an update to the Active Directory Schema and as a safety-net had switched off one of our domain controllers whilst he did it. The DC (2008 R2) that was switched off was at the time acting as the automatically determined bridgehead server for the site.
Obviously the next thing that has to happen is for the KCC to run, discover the bridgehead server is still offline and re-nominate. My colleague thinks that this re-nomination should take upto 2 hours to happen. However all the documentation I can find suggests that this should be every 15 minutes. His argument is that it is a process of sampling, that it realises the problem every 15 minutes but can take upto 2 hours to actually action the change of bridgehead.
Can anyone tell me which of us is right please and if we could have a problem?”
We are running an exchange program between MS Support and MS Premier Field Engineering and our current guest is AD topology guru Keith Brewer. He replied in exhaustive detail here:
http://social.technet.microsoft.com/Forums/en/winserverDS/thread/0d10914f-c44c-425a-8344-3dfbac3ed955
Attaboy Keith, now you’re doing it our way – when in doubt, use overwhelming force.
Unless it doesn’t.
Until next time.
Ned “and return to Han shooting first!” Pyle
Hi all, Ned here again. I’ve been asked a few times if other operating systems can utilize DFS Namespaces running on Windows Server. It’s a sticky wicket; as a “voice of Microsoft” my statements carry a lot of weight - deserved or not. It’s not smart or ethical for me to say that something not made by Microsoft works well, works better than something else, or doesn’t work at all. In some cases, lawyers may be summoned from Vhoorl.
With that in mind I am treading lightly. Feel free to discuss further vendor options in the comments area, we have that precedent.
An OS needs to implement a DFS client to use Namespaces. If the OS doesn’t provide one, you will have to find a third party. It’s one thing to support SMB/CIFS these days –it has become the de facto standard for file servers. But it’s something else to support DFS; this requires new logic and an understanding of the referral process.
Microsoft doesn’t make an out of band DFS client anymore, only the one that comes in Windows itself. Because of the requirement to use DFS in Active Directory (for SYSVOL and group policy processing), we have to guarantee an in-box client exists. We do this through the client redirector and a filtering driver called MUP.SYS. This diagram is a bit out of date but it gives you the gist:
Let’s talk about some others.
The current Mac OS is based on the UNIX XNU, Mach, and FreeBSD kernels. OS X implements SMB connectivity - but not through Samba. According to the Apple discussion forums, Apple uses a very old version of FreeBSD smbfs and while it lets you connect to a DFS path starting in 10.5, it does not understand permissions or allow you to access files.
You therefore need to purchase a 3rd party add-on. Apple lists a few on their website, so I consider that their answer and I don’t mind feeding you a search link:
http://www.bing.com/search?q=dfs+site%3Aapple.com%2Fdownloads%2F&form=QBRE&qs=n&sk=&sc=8-29
Make sure you read Apple’s fine print before you try to call them for support:
Apple is providing links to these applications as a courtesy, and makes no representations regarding the applications or any information related thereto. Any questions, complaints or claims regarding the applications must be directed to the appropriate software vendor.
I find a few more that are not listed by Apple:
http://www.bing.com/search?q=DFS+support+for+Mac+&form=QBRE&qs=n&sk=
As far as IOS 4.x native support goes, I found nothing at all. You will need a third party add-on to implement SMB/CIFS on iPad, according to Apple. No word on whether that means DFS too.
By some people’s definition the Linux Kernel does not have a remote file system (or a local file system); it’s all modular goo. In reality, people usually go through a specific distro and in some later kernels CIFS support is becoming standard . In nearly all cases you can use Samba, so I don’t mind pointing you to it:
Interestingly, Samba’s website also points to number of other CIFS clients, most of which no longer seem to exist (see the bottom of this page):
http://samba.org/samba/download/
There was also smbfs for Linux but it has been discarded and is no longer maintained (perhaps why Apple’s OS behaves as it does; from looking around this client is not being maintained in other OSs either).
Update: One of our awesome readers had some more distro-specific experience to share with us. Thanks Bill!
Red Hat added DFS support to their kernel-level CIFS driver in Red Hat Enterprise Linux version 5.3, though the feature was rather underreported (one of the few search results I found that reported the change was http://www.h-online.com/newsticker/news/item/What-s-new-in-Red-Hat-Enterprise-Linux-5-3-739737.html). Instructions for for testing it out are at http://blog.evad.info/2009/02/21/how-to-use-cifs-dfs-in-red-hat-enterprise-linux-53/. Apparently the code was checked in the Linux kernel in version 2.6.25 and is also available in the Ubuntu distribution as of version 8.10. I haven't gone back and tested it in quite a while, but from what I recall, it worked fine with stand-alone DFS namespaces; I never tested it with a domain-based namespace.
Google has not released Chrome OS as of this writing (it slipped to sometime in mid-late 2011). Chromium is an open source project you can build yourself but it is so new and so amorphous I can’t find any statements on its support of DFS or even CIFS/SMB. It’s based on BSD so one might assume it will implement smbfs (with the DFS limitations that this entails), but one hopes that Samba would be possible. With the coming of Android Honeycomb the future is looking cannibalistic so Chrome may never get the backing it needs to bother with DFS. And with both OSs being marketed in a very consumer-oriented fashion (much like Apple), your calls for DFS may end up falling on deaf ears. Let us know how it pans out.
Until next time,
Ned “it hurts when I do this” Pyle
Updated to include SP1 being RTM and some last minute fixes that were included post RC
Hi all, Ned here again. Back in October I joined the Windows Server 2008 R2 Service Pack 1 beta support team. Our job is to support customers in a special early adopters program. As SP1 has now released, I’m frequently asked about what changes were added for Directory Services. Today I address some specifics:
Remember, the QFEs listed below are all publically available, so if you are skimming the list and have a “oh heck, we’re having that issue” moment you can install anytime. Some of these issues are preventable as well so use your best judgment – an update to prevent NTFS corruption doesn’t fix the damaged files, after all.
Release the Kraken!
This scenario referenced by the release notes refers to:
You cannot create or delete managed service accounts in a perimeter network in Windows 7 or in Windows Server 2008 R2 - http://support.microsoft.com/kb/978836
In this case you have RODCs in a network that users can directly access, but those same users cannot access writable DCs (a DMZ or oddly configured branch office). After you apply SP1 the RODC will know how to forward the request on to a writable DC for MSA operations.
To fix it is install SP1 (or that hotfix) on all your RODCs.
A time-out error occurs when many NTLM authentication requests are sent from a computer that is running Windows Server 2008 R2, Windows 7, Windows Server 2008, or Windows Vista in a high latency network - http://support.microsoft.com/kb/975363
This one is more complicated. Netlogon has a "throttle" that controls the maximum number of simultaneous calls over a secure channel. On DCs this includes the secure channels of external trusted domains (i.e. not Kerberos forest trusts). On member computers this is to authenticating DCs for intra-forest requests or requests to other domains/forests. On high latency networks with a ton of NTLM authentication, applications could start having issues authenticating, ranging from slow performance to errors. MaxConcurrentAPI controls this through a registry value:
Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Value Name: MaxConcurrentApi Data Type: REG_DWORD
The default value if this registry value name does not exist is 1 if a DC, 2 if a member server, and 1 if a client – it has been since NT 4.0 and that has never changed. Until this update is applied, the maximum value is 10. After the update is installed, the maximum value is 150. Generally speaking, since DCs are authenticating users and most companies are not heavily using local member accounts, it only needs to be set on domain controllers.
For all those folks that got scared when we recommended setting the value to 10 in order to fix your issue, this is the proof that you were being paranoid. :) You will see more DC memory usage when you raise the value, but your alternative is obviously far worse.
This has no effect on Kerberos at all and Kerberos is not restricted in this fashion. If you’re using NTLM unnecessarily (misconfigured app, older version app, crummy app, external trust instead of forest trust, etc.) then getting Kerberos in gear is a much better solution than registry band-aids.
There are 795 public fixes that were rolled into SP1 and they’re all listed here:
Hotfixes and Security Updates included in Windows 7 and Windows Server 2008 R2 Service Pack 1.xls
Of these, 104 can be considered “pure” Directory Services updates if you go off the list of what gets supported by the DS team here in Microsoft. Another 59 updates fix things that victimize DS – stuff like networking, file system, SMB, or backups. There are other fixes in SP1 as well. Sometimes issues never get public attention or a QFE would be too expensive or risky; service pack testing is far more comprehensive. I’m not including security updates, you already have those from Windows Update (right?!)
There are some fairly interesting new things here besides the two arbitrary ones in the release notes, I recommend giving these tables a look. For example:
And the issue you are least likely to hit?
KB980598 - Windows Server 2008 R2 cannot be installed or started on a computer that has 1 TB or more of RAM
Holy Schnike, I wish I had that “problem”…
- Ned “640GB ought to be enough for anybody” Pyle
Quick update for everyone – there were two articles released last week:
KB
Title
2492852
SYSVOL Migrations from FRS to DFSR may fail when migrating on Windows Server 2008 SP1
2459083
Robocopy may report error 1338 "The security descriptor structure is invalid" or error 87 "The parameter is incorrect" when copying data from CIFS file servers.
Hey all, Ned here again. Welcome back from Christmas, New Years, etc. Today we talk some BitLocker, SSL, DFS, FRS, MS news, and some geeky goo. Despite us being offline for the past few weeks, we weren’t deluged with new questions – glad you took some time off, you deserved it.
Yoink!
Is it possible to have the Windows 7 machines that have been BitLocker’ed before the AD DS backup was setup automatically check in and store their recovery information? I have seen the two manage-bde commands that are needed but I was wondering if there was a script somewhere that could run at logon or system start up to register all those keys.
Yes, our sister site AskCore has a sample VBS you can use:
http://blogs.technet.com/b/askcore/archive/2010/04/06/how-to-backup-recovery-information-in-ad-after-bitlocker-is-turned-on-in-windows-7.aspx
Despite the security and AD nature of BitLocker, it is not supported by us in DS – instead, the core operating system team handles it, as they own storage. Punt!
Please summarize the support (or lack thereof) for receiving fragmented SSL/TLS handshake messages by OS version and service pack. Which, if any, service pack(s) of WinXP or Vista supports receipt of fragmented handshake messages? For each OS/version that supports receipt of fragmented handshake messages:
[From Jonathan, naturally]
Only Windows 7 and Windows Server 2008 R2 have support for SSL record fragmentation, and then only so far as to accept and coalesce fragmented records. This support was introduced in the RTM release, and does not require a service pack update. Previous Windows OS versions do not support SSL record fragmentation of any sort.
Per RFC 2246, message length is an unsigned 24-bit integer, so the maximum message length is 16,777,215 ((1<<24) - 1) bytes.
There is no size limit on a certificate itself, but there is a size limit on each individual extension. On Windows, the size of a certificate extension must not exceed 4096 bytes. For example, 151 25-character DNS name entries, plus the overhead for encoding (~2 bytes per name), comes in at 4,081 bytes, just under the 4KB limit.
Fragmented handshake records are supported (exceptions below), including the following cases:
The exceptions are:
I went to add a new server as a DFS replication partner and noticed that on the "Replication Folders" tab is now says "Not Published". I then looked at all the replication objects and they also say "Not Published". The strange thing is our namespaces is still responding and seems to be conforming to the rules in place. Should I go through and republish all the replication groups to the namespace? What would cause this type of thing to happen?
First, some background. The attribute msDFSR-Dfspath on that replicated folder in AD is what stores a DFS Namespace path and lets the GUI populate those values. This is on the global DFSR RF “content” object within a given replication group. For example, a replicated folder named “primarybit” that exists in a replication group called “warrenpritest1” in the “Contoso.com” domain would show this:
Often though, no one ever set this value and it is only noticed a long time later – a problem that never was. :) The only way this normally gets set is if you use DFSMGMT.MSC to first create a DFS Namespace, create some links, then get prompted to configure replication (or if you create an RG and then select “share and publish in namespace”. If you just setup DFSR by itself, this field doesn’t get populated. It has no real effect on DFSR, DFSN, or end users – the field exists purely as a convenience to the administrator so that they know that the replication and namespace are related; just a visual thing for DFSMGMT.MSC.
You can edit the attribute manually to be the DFS Link path you want using ADSIEDIT, but I recommend instead using:
DFSRADMIN.EXE RF SET /RFDFSPath <other options>
Once that’s done it will all fill in:
If you want to see when it might have been deleted, you can use:
REPADMIN /SHOWMETA <DN of that content set>
It will show when they were modified:
[After a bit further chatting in the above Q & A]
It turns out that happened exactly when I migrated to 2008 mode in DFS. I wonder if I missed a step or something?
Ah! So that would be expected – when you “migrate” DFSN between modes you are actually recreating them from scratch. When the namespace is deleted that value is being cleaned out, but never put back – because the DFSN migration tools have no idea about DFSR at all. If you wanted to fix that as part of your migration, you can just add the DFSRADMIN command above to your steps.
I was using FRSDIAG to look at a system. The connstat.txt log file it created is blank. Do you know what can cause this?
Anything that makes the command NTFRSUTIL.EXE SETS not work normally will cause this; FRSDIAG just calls that command-line tool then parses the NTFRS_SETS.TXT output to make connstat.txt.
In this case it was FRS being in Journal Wrap. Since the NTFRS_SETS.TXT log only showed “DOMAIN SYSTEM VOLUME (SYSVOL SHARE) in state JRNL_WRAP_ERROR... DELETED REPLICA SETS” there was nothing useful to parse.
I’ve also seen it when a server had all of its FRS replica registry settings removed from under the Parameters registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets <-- gone
The service will start up and you will get an FRS event 13516. But then nothing will replicate ever. You will have to use a D2 non-authoritative restore to fix the server.
Want another way to know when the AskDS blog is updated? You can use the NetworkedBlogs Facebook App. This does not mean that I am going to create a Facebook account for myself. Not doing Twitter either. I got into computers 25 years ago to avoid being social.
On that subject, Mark sent in a link that any self-respecting geek should read: “Wake Up Geek Culture. Time to Die”. It’s written by Patton Oswalt, who is awesome and usually totally NSFW; in this case he kept it mostly PG. Just to prime the pump:
When our coworkers nodded along to Springsteen and Madonna songs at the local Bennigan’s, my select friends and I would quietly trade out-of-context lines from Monty Python sketches—a thieves’ cant, a code language used for identification. We needed it, too, because the essence of our culture—our “escape hatch” culture—would begin to change in 1987. That was the year the final issue of Watchmen came out, in October. After that, it seemed like everything that was part of my otaku world was out in the open and up for grabs, if only out of context. I wasn’t seeing the hard line between “nerds” and “normals” anymore. It was the last year that a T-shirt or music preference or pastime (Dungeons & Dragons had long since lost its dangerous, Satanic, suicide-inducing street cred) could set you apart from the surface dwellers. Pretty soon, being the only person who was into something didn’t make you outcast; it made you ahead of the curve and someone people were quicker to befriend than shun. Ironically, surface dwellers began repurposing the symbols and phrases and tokens of the erstwhile outcast underground. Fast-forward to now: Boba Fett’s helmet emblazoned on sleeveless T-shirts worn by gym douches hefting dumbbells. The Glee kids performing the songs from The Rocky Horror Picture Show. And Toad the Wet Sprocket, a band that took its name from a Monty Python riff, joining the permanent soundtrack of a night out at Bennigan’s. Our below-the-topsoil passions have been rudely dug up and displayed in the noonday sun. The Lord of the Rings used to be ours and only ours simply because of the sheer ******* thickness of the books. Twenty years later, the entire cast and crew would be trooping onstage at the Oscars to collect their statuettes, and replicas of the One Ring would be sold as bling.
When our coworkers nodded along to Springsteen and Madonna songs at the local Bennigan’s, my select friends and I would quietly trade out-of-context lines from Monty Python sketches—a thieves’ cant, a code language used for identification. We needed it, too, because the essence of our culture—our “escape hatch” culture—would begin to change in 1987.
That was the year the final issue of Watchmen came out, in October. After that, it seemed like everything that was part of my otaku world was out in the open and up for grabs, if only out of context. I wasn’t seeing the hard line between “nerds” and “normals” anymore. It was the last year that a T-shirt or music preference or pastime (Dungeons & Dragons had long since lost its dangerous, Satanic, suicide-inducing street cred) could set you apart from the surface dwellers. Pretty soon, being the only person who was into something didn’t make you outcast; it made you ahead of the curve and someone people were quicker to befriend than shun. Ironically, surface dwellers began repurposing the symbols and phrases and tokens of the erstwhile outcast underground.
Fast-forward to now: Boba Fett’s helmet emblazoned on sleeveless T-shirts worn by gym douches hefting dumbbells. The Glee kids performing the songs from The Rocky Horror Picture Show. And Toad the Wet Sprocket, a band that took its name from a Monty Python riff, joining the permanent soundtrack of a night out at Bennigan’s. Our below-the-topsoil passions have been rudely dug up and displayed in the noonday sun. The Lord of the Rings used to be ours and only ours simply because of the sheer ******* thickness of the books. Twenty years later, the entire cast and crew would be trooping onstage at the Oscars to collect their statuettes, and replicas of the One Ring would be sold as bling.
For the record, I know the last words of Roy Batty too and it sickens me.
Next, the best Kinect hack yet – Ultra Seven!
Definitely watch the whole thing. Hopefully there will be no Ultraman versus Spectreman slap fights in the comments section. Tokusatsu always seems to get people’s blood up.
If you don’t follow IO9 and Rock Paper Shotgun you are not maximizing your egghead quotient. They have started off the year with a few must-reads if you are a sci-fi or PC gaming spaz like myself:
There was plenty of interesting stuff at CES 2011, but the thing that caught my eye was the new Touch Mouse. How exciting can a mouse with no buttons be, right? Watch this video:
Finally, in case you missed it, we are going to start supporting System on a Chip RISC processors in the next version of Windows – specifically ARM. Everything old is new again! According to NVIDIA this is the end of Intel and AMD, but I wouldn’t start throwing away all your x86 motherboards just yet.
Ned “can you at least fry the chicken head?” Pyle