Microsoft's official enterprise support blog for AD DS and more
The first data point that is in a Performance Monitor log .csv file may be a larger number than expected in a Windows Server 2003-based domain
File Services management pack has been released
ADFS/SharePoint webcast w/Brjann Brekkan
Group Policy Setting of the Week 26 – Do not automatically make redirected folders available offline
Work Remotely with Windows PowerShell without using Remoting or WinRM
File Services Management Pack for System Center Operation Manager 2007 is available
KB978098 Focus: Large “Folder Redirection” issue
The case of the blank file properties dialog
Configuring applications in Windows with Group Policy preferences
Moving the NTP service to a new PDCe
How to exclude individual users or computers from a Group Policy Object
Run Diagnostics to Check Your System for Memory Problems
Locating Domain Controllers To Access The Default Domain DFS (SYSVOL/NETLOGON)
Infrastructure Planning and Design Guides
Information About Upgrading to Windows Server 2008 R2 AD
AD Schema Changes Made by Exchange
New Networking-related KB articles for the week of May 9 – May 15
Enable and Use Remote Commands in Windows PowerShell
AD FS 2.0 … a SAML Promise Delivered!
AD FS 2 proxy management
File upload/download and remote program execution using WS-Management
Issuing Information Cards with AD FS 2.0
Servicing a Server Core Installation
Manage Windows 7 Power Options from the Command Line
Designing and Implementing a PKI: Part I Design and Planning
Designing and Implementing a PKI: Part II Implementation Phases and Certificate Authority Installation
Designing and Implementing a PKI: Part III Certificate Templates
Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival
Designing and Implementing a PKI: Part V Disaster Recovery
Chris here again. In this segment I will be covering setting up certificate templates on the newly created CA hierarchy. Enterprise Certification Authorities (CAs), as well as clients, utilize what are called certificate templates. Certificate templates contain properties that would be common to all certificates issued by the CA based on that template. Windows includes several predefined templates, but Administrators also have the ability to create their own templates specific for their enterprise. When requesting a certificate, a client can just specify the template name in the request and the CA will build the certificate based upon the requestor’s information in Active Directory and the properties defined in the template.
Certificate templates are also used to define the enrollment policy on the CA. First, an Enterprise CA can only issue certificates based upon the templates it is configure to use. For example, if the CorpUserEmail template is not available on the CA then the CA cannot issue certificates based on that template. Second, permissions set on the certificate template’s Active Directory object determine whether or not a user or computer is permitted to request a certificate based on that template. If a user does not have Enroll permissions on a particular template, the CA will deny any request submitted by the user for a certificate based on that template.
As the Windows Server operating system has evolved over the last ten years, so has the concept of the certificate template. Currently, there are three versions of templates:
Version 1 templates were introduced in Windows 2000, and can be used by Windows 2000, Windows Server 2003 (R2), and Windows Server 2008 (R2) Enterprise CAs. Version 1 templates Active Directory objects are created the first time an Enterprise CA is created in the forest. These templates were designed to reflect the most common scenarios for digital certificates in the Enterprise. Unfortunately, if you don’t like the settings we selected you’re pretty much out of luck. Creating new v1 templates, or editing the existing templates, is not supported. The only customization supported is to the permissions on the template.
Version 2 templates were introduced in Windows Server 2003 and are a vast improvement over v1 templates. First and foremost, v2 templates can be modified by an Enterprise Admin. In addition, the Admin can duplicate an existing v1 or v2 template to create a new v2 template, and then customize the result. Finally, v2 templates expose a larger number of properties that can be configured, and also expose some controls to take advantage of some other new features introduced in Windows Server 2003. One of these features, for example, is key archival. Version 2 templates can be used by Windows Server 2003 and Windows Server 2008 Enterprise or Datacenter Editions. On Windows Server 2008 R2, v2 templates can be used by a CA installed on Standard, Enterprise, Datacenter, Foundation and Server Core Editions.
Version 3 templates were introduced in Windows Server 2008. Version 3 templates have all the features of a version 2 template with two major additions. First, v3 templates support the use of Crypto Next Generation (CNG) providers, which means that the certificates support Suite B algorithms based on Elliptical Curve Cryptography (ECC). Second, v3 templates have a setting that instructs Windows to grant the Network Service account access to the private key created on the requesting computer. This is great for those certificates that will be used by applications or services that run as Network Service rather than Local System. Version 3 templates are supported by CAs installed on Windows Server 2008 Enterprise and Datacenter Editions. They are also supported by CAs installed on Windows Server 2008 R2 Standard, Enterprise, Datacenter, Foundation and Server Core Editions.
For a complete table of Windows Server SKU and the features supported by it, check out this blog post by the Windows PKI development team.
For the purpose of example, I am going to use a fictional company called Fabrikam. The diligent IT staff at Fabrikam have done their research, performed some testing, consulted the auguries, and they’ve determined what types of certificates they need to issue to meet the specified business needs. The next step is to look at what templates are available that they can use out of the box and which ones they need to modify to suit their purposes.
Here’s a quick overview of what Fabrikam determined:
CA Issuance: Domain Controller Authentication, Web Server, and User certificates Key Archival: The private keys for User certificates should be archived Doman Controller Authentication template: No additional requirements Web Server template:
User Certificate Template:
Fabrikam has decided that they need to deploy the following certificate templates: Domain Controller Authentication, Web Server, and User. In addition, the fact that Key Archival is to be enabled for the User template means that the CA should also be configured to issue certificates based on the Key Recovery Agent template (Actually, this is not a requirement if there is another Windows Enterprise CA in environment that is configured to issue Key Recovery Agent certificates, and is trusted to do so.)
Let’s assume that the PKI hierarchy has been set up and is functional. The next step is to configure the certificate templates. Let’s check the configuration of the templates before deploying them.
To manage the certificate templates, you use the Certificate Templates MMC snap-in. In the Certificate Services MMC snap-in, right-click on the Certificate Templates folder and select Manage from the context menu.
In the view pane of the Certificate Templates snap-in you’ll see all the certificate templates available in Active Directory. If you locate the Domain Controller Authentication template and double-click on it, you’ll see the properties available for that template. Our fictional IT staff has already reviewed the settings and determined that no changes need to be made, so we’ll just click Cancel, here.
Next, locate the Web Server template. The default Web Server template already meets the current requirements that arose from an analysis of business needs. However, to allow for future changes Fabrikam has decided that they need to duplicate this default template and create a v2 template.
To duplicate the existing Web Server template and create Version 2 template:
1. I right click on the Web Server template and select Duplicate Template from the context menu. Fabrikam still has a lot of Windows Server 2003 servers and Windows XP workstations (But they are steadily upgrading. No, really! They are!! Trust me! Sigh.) This means that we can’t use the latest and greatest v3 templates available on our Windows Server 2008 CA. We’ll have to specify that we’re creating a template for Windows 2003 Server, Enterprise Edition which will create a v2 certificate template.
2. We’ll give a new name to the template: Fabrikam WebServer.
3. Clients within Fabrikam will connect to the web servers via the server’s DNS name. This means that the requesting server’s fully qualified DNS name must be in the Subject of the certificate it receives. To meet this requirement, click on the Subject Name tab and select Build from this Active Directory information. For the Subject Name Format, select DNS Name. Finally, deselect all of the check boxes under Include this information in the alternate Subject name.
Now that the new template is configured per the specified requirements, we need to set the security. The computer account for a particular web server will be the principal enrolling for the Fabrikam WebServer template, so we have to make sure that all the web server computer accounts have Enroll permission on the new template. Fabrikam, luckily, has a Security Group containing all of their web servers called, oddly enough, Fabrikam Web Servers. We can simply grant the necessary permissions to that group.
We’ll use essentially the same process to duplicate the default User template and modify the resulting v2 template to suit Fabrikam’s requirements.
Just as with the default WebServer, we’ll duplicate the existing User template to create the custom v2 template. We need to do this because the default User template is a v1 template, so its properties cannot be modified. One of our requirements is to enable Key Archival which requires configuring a setting in the template, so in order to do this a v2 template is required.
To create and configure our new User template:
Although this template was not mentioned as one of Fabrikam’s requirements, it is a requirement to issue at least one Key Recovery Agent certificate to support Key Archival. This step is only necessary if there is not another Windows Enterprise CA configured to issue certificates based on the Key Recovery Agent template.
For this example, however, let’s assume that there is not and go ahead and configure the Key Recovery Agent template. The only setting that requires modification is the permissions. We’ll assign enroll permissions to the Fabrikam KRA security group so that members of that group can enroll for a Key Recovery Agent certificate.
To configure the CA to issue the desired certificate templates, I right-click on the Certificate Templates folder, select New, then select Certificate Templates to Issue from the context menu.
Then I select the certificate templates I wish to issue, by holding down the control key and selecting multiple templates, and then clicking OK.
This CA can now issue certificates based on the selected certificated templates.
That’s really all there is to it. While in this segment we only modified a few properties of our templates, in the vast majority of cases there should be no need for making extreme changes. The default templates should be sufficient for most implementations, and the changes we made were more to ease certificate deployment than actually create truly custom templates. Perhaps in a later blog post we’ll cover some of the more esoteric settings. However, this shouldn’t stop you from exploring on your own using the online help.
In Part IV of this series we’ll cover implementing Web Enrollment and Key Archival.
Heya, Ned here again. I am out of my barrel and on the road again this week, coming to you live from Las Colinas Texas. As you may have noticed, I recently wrote a TechNet Whitepaper on how to migrate your old custom FRS data to DFSR. Hopefully that's been useful.
In the meantime though, Mike Stephens and I also created a free migration tool. Because I am lazy very busy I am simply going to repost from our download page at Code Gallery. I hope you find this useful.
FRS2DFSR is a utility that assists Windows admins in moving from the legacy File Replication Service (FRS) to the newer Distributed File System Replication (DFSR) service. Because FRS is no longer supported except for SYSVOL starting in Windows Server 2008 R2 and because Windows 2000 support ends on July 13 2010, this utility can help unblock admins from migrating to newer operating systems. The tool is written in C# .NET and can be run on x64 and x86 Windows Server 2003/2008/2008 R2 and Windows Vista/7 with DFSR RSAT installed. It requires domain admin rights and is command-line only. FRS2DFSR.EXE exports an existing File Replication Service replica set, deletes the replica set in Active Directory and creates DFS Replication group with the same servers, folders, connections, and settings. See the release notes for utility limitations. This tool is not used for SYSVOL migrations, see below for steps on using DFSRMIG.EXE in that scenario.
Important support information:
This tool is provided as-is, without warranty and is not supported by Microsoft Commericial Technical Support (aka CTS, PSS, CSS, EPS). No official support cases may be opened against this tool. It is intended only as a fully functional sample. Use the Discussions and Issue tracker tabs to report issues.
For a supported set of steps for migrating from FRS to DFSR for custom sets, see:
DFS Operations Guide: Migrating from FRS to DFS Replicationhttp://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a27008a8-4b28-49cc-80b5-05b867440af9
To migrate SYSVOL, use the DFSRMIG.EXE tool included in Windows and reference:
SYSVOL Replication Migration Guide: FRS to DFS Replicationhttp://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=df8e5e84-c6c6-4cef-9dab-304c92299804
- Ned "and Mike Stephens" Pyle
Hey all, Rob here again. I thought I would expand upon my last blog describing Certificate Enrollment Web Services by covering some of the different configurations that are possible.
As a refresher, Certificate Enrollment Policy and Certificate Enrollment Services abstracts certificate Policy and certificate Enrollment from a specific Active Directory forest allowing clients in a different forest -- or no forest -- to request and obtain certificates.
So here is a simple network diagram of what I am setting up in this blog post.
A non-domain joined computer on the Internet needs to be able to enroll for certificates from a Microsoft Enterprise Certification Authority. We are configuring the CEP/CES web services to interact with the Internet-based computer and this computer has no network connectivity to domain controllers or certification authorities behind the firewall. You could also further isolate the domain controllers and certification authorities by placing the CEP/CES server(s) in a perimeter network with another firewall between CEP/CES and the internal network.
First you need to install the CEP and CES roles on the member server Win2K8R2-MEM1.
For those of you well versed in getting certificates issued through IIS and how to setup the websites to require SSL you can skip this section.
Now that you have the services installed and the IIS configuration completed, you need to focus on the URI sent to the client computer to which it will send the enrollment request.
Alright, you are almost done with the setup now. The last thing you have to do is configure the clients to use the CEP/CES services.
Before clients will enroll for certificates against a certification authority hierarchy, they must have the public Root CA certificate in the computer’s trusted root store. This part of the configuration is probably the most difficult since these are not domain computers and you will have to rely on the user to follow the steps. There are two ways to do this – through the snap-in, or with a command-line that you could give to the user as a batch script.
Before I go into the steps it is important to understand that this configuration is based on the security context. You have a CEP configuration for the user, and you have another configuration for the computer. Depending on what certificates you plan on issuing (user or computer certificates) you may only require one of these to be configured.
With the users certificate store MMC still open do the following:
Now you may be asking “how can I get this configuration deployed to users?” And you may be thinking “these steps are way too complicated for them to follow.” Well, you can export the configuration from the registry and have the users import the settings.
Computer CEP configuration is located here: HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\PolicyServers\<GUID>
Use CEP configuration is located here: HKEY_CURRENT_USER\Software\Microsoft\Cryptography\PolicyServers\<GUID>
Alright, so you got your non-domain joined client computers requesting and getting certificates over the Internet. Great job! There are two different topics to be discussed for advanced configurations:
1. You have multiple CES servers or multiple authentication methods (Kerberos, Username Password, or Certificate) in your environment.
2. You want to use the CEP and CES services on the same computer, and use a domain or managed service account for the web application pool.
If you have multiple CES servers that host different authentication methods or one CES server that hosts multiple authentication type web services, you need to be concerned with the priority of the authentication methods you specify. If you recall from the section “Modification of msPKI-Enrollment-Servers attribute”, those changes assume that this is the only CES server and authentication method you are implementing in your environment. If you need to support multiple authentication methods then the CES URI needs to be added in a different way to assign different priorities to each authentication method.
The first thing to understand is that the lower the priority number the more preferred the CES URI is. So a priority of 100 is more preferred then that of 200. If you want to find out the different CES authentication types assigned to a certain CA and the priority you can type the following CertUtil command: certUtil –config “<CA Computer Name>\<CA Name>” -enrollmentServerURL
CertUtil –config “fab-rt-ca1.fabrikam.com\Fabrikam Root CA1” –enrollmentServerURL
As you can see from the output in Figure 15 there are two authentication methods assigned to the Fabrikam Root CA1. You have Kerberos at a Priority of 100, and UsernamePassword at a priority of 200. You can also see that the URL addresses are different. External clients would not resolve the win2k8r2.fabrikam.com DNS name, and internal clients would prefer Kerberos authentication over the UserNamePassword method because the priority for Kerberos is lower. Failure to set the priorities correctly could cause domain joined client computers to prefer UsernamePassword authentication method over Kerberos, and you will get a lot of calls to the help desk asking why the computer is constantly asking for credentials.
Alright, if you are reading this section, you must be really serious about security, and using domain based service accounts to run application pools. As stated earlier, during the installation phase if the CEP and CES web services are running on the same server then the application pool accounts for both of these services must be using the same account.
So in a nutshell, that’s pretty much how you can configure CEP/CES to allow users on non-domain joined clients to enroll for certificates against an internal Enterprise CA. Stay tuned in the future when we’ll cover some other scenarios featuring CEP/CES in Windows Server 2008 R2.
I hope that you have enjoyed learning how to use CEP and CES to extend certificate issuance to your users and customers.
Rob “Unjoined” Greene
Hi, it’s Adam Conkle again. I am excited about our recent release of AD FS 2.0 on May 5. I wanted to post a blog about AD FS 2.0 and AD FS 1.x interoperability as soon as possible since I think it will be a common scenario for our customers.
AD FS 2.0 and AD FS 1.x interoperability was a priority for this release, and full functionality of AD FS 1.x security token servers (STS) and the Claims-aware Web Agent is supported in AD FS 2.0.
Note: AD FS 2.0 does not support the AD FS 1.x Windows Token Web Agent
In order to federate between the two versions of AD FS there are some requirements that we need to manually address.
AD FS 1.x includes three claim types:
Below, I will describe methods to send claims from AD FS 2.0 which satisfy the AD FS 1.x claim requirements.
We will be extracting several claims from an Attribute Store, and, before we begin, we need to understand where the extractions should take place. You can extract from the Attribute Store either on the Claims Provider (CP) Trust or on the Relying Party (RP) Trust. Both will work; the difference is this:
When you extract using the CP Trust rules, the claims are injected into the policy processing pipeline early in the process. Then, on the RP Trust, we execute the Issuance Authorization Rules and can make RP authorization decisions based on claims that we already have in the pipeline.
When you extract using the RP Trust rules, the claims are injected into the pipeline later in the process, and any Issuance Authorization Rules you have configured for the RP Trust will not apply to claims which are issued here since the authorization rules have already executed.
In AD FS 1.x, we require at least one Identity Claim (UPN, Email, or Common Name). The Identity Claim is sent as the subject of the SAML 1.1 assertion as a claim called Name Identifier (Name ID). Name Identifier also has a format property which equals the URI of the primary Identity Claim sent. For example, if userPrincipalName (UPN) is sent as the primary Identity Claim, then the Name Identifier claim is specified with the format of UPN with the claim value equal to the UPN of the authenticating user.
Here is a snippet of AD FS 1.x SAML assertion showing the Name Identifier claim:
When we utilize AD FS 2.0 there is no concept of Identity Claims, and we also do not automatically send a Name ID claim. This needs to be manually configured so that AD FS 2.0 will send the Name ID claim to the AD FS 1.x server in a format that the AD FS 1.x server is expecting. Simply issuing a UPN claim from AD FS 2.0 to AD FS 1.x does not achieve the requirement, and a Claim Rule is needed.
Let’s go to the AD FS 2.0 STS, and let’s also assume that AD FS 2.0 is the identity provider (IdP) for this federation scenario. We will configure an Acceptance Transform Rule for the Active Directory CP Trust which extracts userPrincipalName from Active Directory as the UPN claim type (URI). Creating this rule on the CP Trust will place the UPN claim into the pipeline prior to any RP Trust rules firing.
When you create this rule, use the Send LDAP Attributes as Claims template in the rule editor.
Figure 1 – Selecting a claim rule template to extract from AD
Figure 2 and Figure 3 show a rule named Extract UPN from AD which has been added to the claim rules for the Active Directory CP Trust.
Figure 2 – Configuring the Claim Rule to extract UPN from AD
Figure 3 – New rule has been created to extract UPN from AD
Now that we have a UPN claim in the pipeline, the next step is to transform this claim into the format that AD FS 1.x requires: Name ID. We perform the transformation with an Issuance Transform Rule on the AD FS 1.x RP Trust.
To create a transformation rule, use the Transform an Incoming Claim template in the rule editor
Figure 4 – Selecting a claim rule template to transform a claim
Configure the rule to transform from the Incoming claim type: UPN to the Outgoing claim type: Name ID. Once you select Name ID as the outgoing claim type, the Outgoing name ID format drop-down box becomes available so that we can select the UPN format for Name ID. We want to pass the value of the user’s UPN to the new claim, so select Pass through all claim values.
Figure 5 – Configuring the transformation rule for Name ID
When a user authenticates to the AD FS 2.0 STS, the UPN will be extracted from AD during execution of the AD CP Trust rules and injected into the pipeline. Next, the processing rules are executed for the AD FS 1.x RP Trust, and UPN will be transformed to Name ID with the UPN format. The value of the user’s UPN is maintained for the outgoing claim to the RP (AD FS 1.x).
Now that we have the Name ID claim handled, we still need to send the appropriate Identity Claim(s) to AD FS 1.x. For that purpose, AD FS 2.0 includes Claim Descriptions for AD FS 1.x UPN and AD FS 1.x E-Mail Address.
Figure 6 – AD FS 1.x Claim Descriptions shown in the Claim Descriptions node of AD FS 2.0
We simply need to extract them from our Attribute Store (AD, in my case), and send them to the AD FS 1.x RP.
Figure 7 shows how to configure the claim rule to extract UPN and E-Mail as AD FS 1.x UPN and AD FS 1.x E-Mail Address. I have chosen to create this rule on the CP Trust.
Figure 7 – Configuring a rule to extract AD FS 1.x claims from AD
In Figure 8, I have selected the Pass Through or Filter an Incoming Claim template so I can pass the AD FS 1.x claim types to the AD FS 1.x RP. This rule is created on the RP Trust so that the claims accepted from the AD CP Trust can be passed to the RP.
Figure 8 – Selecting the claim rule template to pass a claim through to the RP
Finally, in Figure 9, I have configured the rule to Pass through all claim values for the Incoming claim type: AD FS 1.x UPN. You will need to create another set of extraction and pass through rules to handle the AD FS 1.x E-Mail Address or Common Name claim types if you wish to send them.
Figure 9 - Configuring a claim rule to pass through the value of the AD FS 1.x UPN claim type
Next, you may need to send Group claims to AD FS 1.x. AD FS 2.0 comes with a built-in Claim Description named Group which has the URI that AD FS 1.x expects for Group Claims. This can be seen on the Claim Descriptions node in the AD FS 2.0 MMC console.
Figure 10 – Group Claim Description on the Claim Descriptions node of AD FS 2.0
AD FS 2.0 also has a Claim Rule template named Send Group Membership as a Claim which allows you to select a security group, and send a claim based on membership of that group. I have chosen to create this rule on the RP Trust.
Figure 11 – Selecting the claim rule template to send a claim based on group membership
Now, all we need is the AD FS 1.x Incoming Group Claim Mapping name the AD FS 1.x administrator is expecting on the resource federation server. For our example, let’s call it SharePointUsersMapping. Our rule looks like this:
Figure 12 – Configuring a claim rule to send a Group claim based on group membership
Since I created my rule on the RP Trust this time, there is no need to create a pass-through rule in order for the claim to be sent to the RP.
We’re on the home stretch now! Finally, we may need to send additional claims to AD FS 1.x which are neither Identity Claims nor Group Claims; they are AD FS 1.x Custom Claims. As an example, I have extended my AD schema to include a user attribute named costCenter. I want to send the users’ cost center as a claim when they authenticate to a resource hosted by my AD FS 1.x partner.
I need to create a new Claim Description to handle this on the AD FS 2.0 STS, but I need to do a bit of background work before I create the new Claim Description. If I take a look at a SAML assertion from AD FS 1.x which contains a Custom Claim, it looks like this:
The way the SAML assertion is constructed here is as follows:
1. The full URI of the claim type is passed in
2. Everything after the last “/” in the URI is stripped off of the URI and is used as the AttributeName property
3. Everything before the last “/” in the URI is used as the AttributeNamespace property
Consider the following full URI:
Now, run that through the steps above:
1. http://schemas.xmlsoap.org/claims/FirstNameMapping is passed in
2. FirstNameMapping is stripped off of the URI and is used as the AttributeName property
3. http://schemas.xmlsoap.org/claims is used as the AttributeNamespace property
I’m ready to create my Claim Description for costCenter, which is accomplished on the Claim Descriptions node of the AD FS 2.0 MMC console:
Figure 13 – Configuring a new Claim Description for Cost Center
The AD FS 1.x administrator will need to create an Incoming Custom Claim Mapping named costCenter so that the incoming claim is mapped.
The last thing we need to do on the AD FS 2.0 federation server is create a rule using the Send LDAP Attributes as Claims template to extract the costCenter attribute from AD and send it to AD FS 1.x as our new claim type. I have chosen to do this on the RP Trust which, again, negates the need for an additional pass-through rule to the RP.
Figure 14 – Configuring a rule template to extract costCenter from AD and send as Cost Center
We’re done! This blog post covers AD FS 2.0 as the Claims Provider (Identity Provider) and AD FS 1.x as the Relying Party (Resource Provider) because it is AD FS 1.x which has the special claims requirements. You can certainly configure AD FS 1.x as the Claims Provider and AD FS 2.0 as the Relying Party, but that deployment should be a bit more straight-forward since AD FS 2.0 simply needs to be configured to accept the incoming claims from AD FS 1.x. Thanks for reading, and please let me know if there are any questions or points needing clarification.
Adam “So He Claims” Conkle
Hello there file server admins and datacenter monitoring gurus, Ned here again. After much skull sweat and gnashing of tooth, the File Services management pack for System Center Operations Manager 2007 has been released.
This new MP covers:
It officially supports monitoring Windows Server 2008 R2 (although actually more, see the filecab link below), and is the younger brother of the 2003/2008 DFSR and DFSN management packs for SCOM 2007.
PS: Jonathan’s description below makes me think I’m in the last scene of Raiders of the Lost Ark…
Jonathan: We have top men working on it now. Mike: Who? Jonathan: Top... men.
Jonathan: We have top men working on it now. Mike: Who? Jonathan: Top... men.
Ned “Indiana” Pyle
Hello, Internetz. Jonathan here again. Ned didn’t tell you the whole story. Not only did I have to wait for the truth serum to wear off; I also had to chew my way out the straps. Nevertheless, I’ve emerged victorious and have again successfully stormed the AskDS gates and vanquished Ned. Don’t fear for the little Neebler, though. Yes, he’s been jammed into a steel drum along the side of one of our nation’s great highways, but he’s being fed well through the bung hole, mostly, and he has a nice view of the Interstate. I hope he enjoys playing Punch Buggy with himself.
Of course, knowing Ned, I give him about a week before he escapes, so let’s make the most of that time, shall we?
AskDS has been successfully migrated to our new blog platform. Unfortunately, the backup that was restored after the migration was older than we thought so we appear to have lost some of our more recent posts. I’m working now to re-post those articles now. Please let us know if I missed one.
--Jonathan “Pretender, Redux” Stephens
Some smart cards performing requests cause performance issues
Errors when you have a large "Folder Redirection" policy settings file in Windows Vista, in Windows 7, in Windows Server 2008, or in Windows Server 2008 R2
Some providers may receive an incorrect password value from the OLEDB32 component if the password in the connection string is blank in Windows 7 or in Windows Server 2008 R2
Wiki Page: AD FS 2.0: Migrate Your AD FS Configuration Database to SQL Server
Wiki Page: Hyper-V: How to Configure Server Core using SCONFIG
Wiki Page: Hyper-V: Performance Guide
Wiki Page: Hyper-V: How to Find the Host of a VM
Migrated Users Get Prompted To Change Password at First Logon Even After Migrating Their Password with the PES
The Next Generation of AD Performance Analysis
Validating your AD Schema Prior to Upgrade (a Followup)
Friday Mail Sack – It’s About To Get Real Edition
Hey, Scripting Guy! Weekend Scripter: Configuring W32Time Service Logging
Considerations when upgrading your Active Directory to Windows Server 2008 and 2008 R2
Group Policy Setting of the Week 25 – Remove the Action Center icon
BPOS Deployments – notes from the field
What's next for Windows Server and beyond?
Announcing the Availability of Active Directory Federation Services 2.0 and Forefront Protection for SharePoint 2010
AD Clients Not Authenticating to its Local Site
Top 10 IAM Challenges for Heterogeneous Enterprises
Eugenio Pace on Identity Federation, WIF, and ADFS 2.0
Free Office Mobile 2010 for Windows Phones
Best Practices for Creating a Secure Guest Account on Windows 7
Choosing an Appropriate User State Virtualization Solution
PowerShell Resource Page at Windows IT Pro
Folder Redirection isn’t working correctly — the redirection targets the wrong server!
The very best Sysinternals tools for Windows server security
Hyper-V Best Practice Analyzer - What does it check
New Networking-related KB articles for the week of May 2 – May 8
New topic and script about testing for Active Directory schema extension conflicts
Adding claim mapping to existing provider in SPS 2010
Using Kerberos security with Server for NFS
Two Minute Drill: The Schtasks command
Windows Intune - Under the Hood
IPv6 transition technologies on Windows Server 2008 R2 Server Core
PowerShell and AD DS Best Practice Analyzer