I’ve been a fan of Server Core since I heard about it and you can see by the 20+ posts I have on the product. Server Core has been out since Windows 2008 which is just under 40 months. Server Core R2 has been out for about 20 months. One of the selling points that Microsoft made on server core was that it would have a reduced attack surface and thus you would have fewer reboots due to patches. While preparing for a talk on Server Core I wanted to investigate this a bit more. I reached out for some help to Andrew Mason (if you don’t know that name you aren’t a Server Core hard core freak like me). Andrew runs the official Server Core blog over on TechNet. Andrew sent me some wonderful information on the subject that I’d like to share with you.
Take a look at these numbers. I’ll explain in more detail below.
We are comparing both Server Core 2008 and R2. The Reduction column is % reduced based off the hotfixes Microsoft released during their existing lifespan. Critical Only is just that, the reduction of patches Microsoft rated Critical for both versions of Server Core.
Now lets look at the rows starting with All applicable patches.
Now we see the area called Necessary patches only. What does that mean? That is referencing the patches that are really needed for Server Core. There are some vulnerabilities that show Server Core as vulnerable but its not exploitable. That is what is called out on the bottom of the graphic. Microsoft does this because it has changed the file and would probably prefer you to update the file eventually too. IMHO I’d patch these but would bundle them with the necessary patches.
I remember reading an article from David Cross on TechNet stating the following “In some cases, customers can see up to a 60% reduction in patch requirements and the number of reboots on a monthly basis” These are the numbers that back up statements such as that.
Those are some pretty impressive numbers. Great job to the whole Server Core team. I really hope Microsoft continues with this product and from recent announcements on the next version of SQL it looks like they are sticking with it.
*Numbers updated through the May 2011 patch Tuesday
Last week I was a speaker at Tech Immersion 2011 here in Phoenix Arizona. I gave four talks on a range of topics that covered Active Directory, PowerShell and Server Core. Hopefully I have some new followers since the conference and if so make sure to say hi in the comments.
The highlight for myself was meeting Jeffrey Snover. If you don’t know who he is then you better Bing or Google him now. This is the father of PowerShell and now the Lead Architect for the Windows Server Division. He was really great to talk, in fact there were a lot of great presenters there including, PowerShell gurus Don Jones & James Brundage, Microsoft Certified Master’s Miguel Wood & Mike Pfeiffer, MVPs and MCTs such as Simon Allardice, Scott Cate, Jeff Jones, Spike Xavier as well as Microsoft employees Michael Palermo, Harold Wong, Tony Harris & Kathrine Lord and ITIL/COBIT Master Mark Thomas. I left one person out and that was on purpose. Jason Helmick…what can I say. He along with the rest of Interface Technical Training put on an excellent conference that will only grow more and more as time goes on. Great job Jason and Lynn from Interface as well as everyone else that supported this event.
Here is a pic of Jeffrey and I after the event hanging out at Dick’s Hideaway.
I can’t wait for Interface to host another great event like this.
Some of you may have used Acctinfo.dll in to get the additional Account Info tab when managing Active Directory from 2003 or Windows XP. It was a great add on that should you additional info about Users such as their GUID and SID amongst many other things.
I’ve heard rumors that some people have seen Acctinfo2.dll out in the wild…aka the Internet and that it works on Server 2008 R2. Please don’t download anything called Acctinfo2.dll from the Internet unless it is officially from Microsoft. I’m not saying that Acctinfo2.dll doesn’t exist…to be honest I have no idea because I’ve never tried to install it. But like you I’m not a fan on downloading something that could potentially do harm to my environment.
For those looking to get those “Additional Account” attributes you can still do it. The first way is to just use the Attributes tab in Active Directory Users and Computers, but there is a an even better way. All you really need to do is use the Active Directory Administration Center. Let me show you.
Once you open the Active Directory Administration Center up you can do a search for the user you want additional info on:
Now either double-click on that account or click the Properties from the Tasks on the right side.
These are the standard account properties…but…did you notice the area called Modified on the bottom? That is where the magic really happens.
Here you can see all sorts of goodies including an account’s SID. Just take a look at all that goodness.
Good stuff indeed. Now stop trying to download something that doesn’t exist except in Area 51.
Here is a few one-liner commands to help get info on your Active Directory environment. I don’t think there is any mind blowing commands here but they’ve helped me out. There are literally hundreds of these around the web as well as PowerShell ones but these are the ones that I’ve been using lately.
How to view the Domains you trust and see what those Domain SIDs are:
nltest /domain_trusts /v
A quick listing of your AD Sites:
dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn description location -filter (objectClass=site)
A quick listing of your AD sites and their Site Links and Costs (sure would be nice if you could spit this out to Visio or something):
dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn costdescription replInterval siteList -filter (objectClass=siteLink)
Compare time against your forest root PDCe:
w32tm /monitor /computers:ForestRootPDC
Find out which DC for a site is the ISTG:
dsquery * "CN=NTDS Site Settings,CN=siteName,CN=Sites,CN=Configuration,DC=forestRootDomain" -attr interSiteTopologyGenerator
Time and time again I run into an issue that presents me with a SID which I need to resolve. I’ve used a number of tools and scripts over the years to address this issue. I think I have the best and easiest method for me to solve this issue that always seems to pop up.
If you’re new to PowerShell you will want to make sure you have it installed if you want to use this script…and yes it is a script not a command. I do this by opening a text file and renaming it from a .txt file to a .ps1 file. When you try to open a .ps1 file it may open in your text editor but for this you will want to Right Click it and select Edit which will open up whatever you have as your PowerShell editor. Copy the following code into the Script Pane:
$objSID = New-Object System.Security.Principal.SecurityIdentifier
("S-1-5-21-768745588-123456789-987654321-500")
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
$objUser.Value
Now just save this file and you can run it to return the results of the SID that you place in there. The one thing that will change is the actual SID. In this example i’m using S-1-5-21-768745588-123456789-987654321-500 which is the Well Known SID for the domain Administrator. My results should show me the friendly name. Anytime you change the SID you will have to resave the file but then just Run the script and it will show you the results.
I’m sure there is a way I could make this into an application but I”ll leave that fun for those looking to take this to the next step.
I was thinking about writing a post about Active Directory replication but thankfully soon realized that by doing so I could be severely depriving my kids and wife of a happy life. Its not that Active Directory replication is bad or harmful, its just that there is so much about it. I don’t care who you are you probably don’t know it all…I certainly don’t and have never claimed too.
While I was doing my research for this post I found what I”d like to call the bible to Active Directory replication. I’m also thankful this was one of the first resources I picked up on and didn’t have to much time invested. Without further ado – How the Active Directory Replication Model Works. I think if you printed this out it would be about 100 pages or so (not confirmed but it is long).
This article goes over every little detail needed to fully understand the Active Directory replication model. I’d love to know the person/team that wrote this and give them my gratitude. I wish stuff like existed for new products. I still remember trying to learn Active Directory when it was in beta back in 1999 and not fully understanding USNs, Up-to-Dateness Vectors and Watermarks.
If you have any good resources on Active Directory replication please feel free to share so others can learn as well.
I’ve blogged several times about the AD Recycle Bin (ADRB). It has been a popular subject here at the Life of Brian and I can see why. It is a feature all AD admins have been screaming about for years. I wanted to spend 5 mins of your life going over two attributes that confuse everyone…even me from time to time.
There are over a dozen attributes that deal with ADRB but I want to focus on two of them, isDeleted and isRecycled. The first time I read through the documentation on these attributes I thought it was pretty straight forward, isDeleted is when an object is deleted and isRecycled is when an attribute is recycled. Well it is NOT that simple. Let me explain these attributes a bit further for your understanding.
The isDeleted attribute has been around since Windows 2000 and exists on every AD object. It describes if an object is deleted (makes sense) but also if it is restorable. After the ADRB is enabled you have the ability to restore deleted objects (that were deleted after it was enabled).
The isRecycled attribute is new to Windows Server 2008 R2 and only exists on an object after it has been recycled. By default, a deleted object will become a recycled object after the msDS-deltedObjectLifetime (another new attribute in Server 2008 R2) expires. Now that object is what I like to call dead dead. This means that you can’t restore it with all its pretty properties. Its kind of like the old way of restoring an object just to get its SID back.
I think you can see where the confusion comes into play. When I hear or read the term isDeleted my gut reaction is to think that it is deleted (dead dead) and when it says isRecycled I think it can be restored fully…well the sad truth is that it is the opposite.
You may be familiar with the traditional ways to transfer FSMO roles but how about by using PowerShell? By now you should just know that PowerShell can do everything the GUI can do…well at least that is the way it feels to me.
If you want to use PowerShell to transfer any of your five FSMO roles (PDC Emulater, RID Master, Infrastructure Master, Domain Naming Master and Schema Master) then you will first need to import the Active Directory Module into PowerShell.
ipmo activedirectory
Now that you have the AD module loaded the cmdlet you will use for this is quite large – Move-ADDirectoryServerOperationMasterRole. Thankfully we have the Get-help cmdlet to help us remember that. All I need to do is remember move-ad and then I press tab to complete the rest. There is only one other cmdlet that is similar to it and you just have to remember you are trying to move the FSMO role and not the sever.
When entering the cmdlet you need to specify the operation master roles to move. the syntax for the five roles are as follows – PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, or DomainNamingMaster. To specify more than one role just separate each role with a comma.
An example of me moving the RID Master and PDC Emulater to DC2 is as follows:
Move-ADDirectoryServerOperationMasterRole -Identity "DC2" -OperationMasterRole RIDMaster,PDCEmulator
A feature that I just love in PowerShell is the –WhatIf parameter. By adding this to your code it will do a dry run and let you know what is going to change if you did the command without that parameter.
One key thing to note here is that I am NOT seizing the FSMO role. For that you will need to use NTDSUtil as defined here.
Stale user accounts can be a big problem…even more so when they are not disabled. I’m a firm believer that if you have an account that is not being used it should be disabled. However depending on the size of your Active Directory that can be a daunting challenge. Below you will find a snippet of code that will identify where user accounts are not being used for 10 weeks and then it has the ability to disable them.
dsquery user -inactive 10 -limit 0
The 10 value is for the number of weeks an account has been inactive. If you think you are going to have a lot of these then you may want to change your limit from 0 to something like 50 or so.
Now if you would like to disable them as well you simply add on another portion of code. For safety reasons I prefer to run the code above first to see who is inactive and then once I’ve validated those accounts can be inactive I run the following code to disable them.
dsquery user -inactive 10 -limit 0 | dsmod user -disabled yes
Obviously the account needs to have the appropriate permissions for dsmod to work so watch out for that. Good luck and happy hunting!
Wow, that is a lot of delegating…seriously how many times can you say it in one sentence. Today’s post is one that threw me for a loop. As a domain admin I have the right to configure constrained Kerberos delegation. There may come a time when you want to delegate that out to a user or group.
My first thought was to assign the user/group Full Control on the OU that included the accounts. At this point I would run the following command
setspn -a http/workstation01 adminprepbrian
Surely Full Control would grant me the permission to do this…Failed!!! Insufficient access rights. It is not a “permission” that is needed, it is a “User Right”. So where do you go to assign rights to work with constrained delegation and what User Right is it? Well, you won’t find it in the Local Security Policy.
The User Right that you need to grant is SeEnableDelegationPrivilege. Now where and how do I grant this User Right. Well it turns out you still should delegate Full Control to the user/group that you want to grant this User Right too. Then on a DC you must run the following command:
ntrights -u adminprepbrian +r SeEnableDelegationPrivilege
Just make sure to modify that domain/user to match your environment. Now when I run the Setspn command it works because that account has the correct User Right. You may have to wait for replication to occur if you are in a distributed environment.