Launch the PowerShell under Administrator’s account context, and type this cmdlet.
Enable-ADOptionalFeature -Identity ‘CN=Recylcle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com
Read and understand the warning of this action’s irreversebility, and hit “Y” for yes to continue.
In following screenshot I show you an error not neccesarily applicable to you, the cmdlet complained about not being able to verify the FSMO ownership role. The reason for this was the fact that in my VM Lab environment I had shut down another DC for maintenance and it had not been replicated or talked to.
As I brought that downed DC back online, forced the replication, I was able to proceed. You can then confirm with this cmdlet.
Get-ADOptionalFeature ‘Recycle Bin Feature’
Here is a great post on this hot feaure of Windows Server 2008 R2.
http://msmvps.com/blogs/ad/archive/2009/03/31/taking-out-the-trash.aspx
Posted: 09-06-2009 | Author: Rick | Category: Server Core, Windows Server 2008 | No comments
As briefly discussed before, a feature to offline domain join machines is available in Windows Server 2008 R2. The utility is called “djoin.exe” which is used to perform this task. Here is an official blurb on what the offline domain join is what it would be used for and then I will show you how to perform this simple task.
“Offline domain join is a new process that computers that run Windows® 7 or Windows Server® 2008 R2 can use to join a domain without contacting a domain controller. This makes it possible to join computers to a domain in locations where there is no connectivity to a corporate network. For example, an organization might need to deploy many virtual machines in a datacenter. Offline domain join makes it possible for the virtual machines to be joined to the domain when they initially start after the installation of the operating system. No additional restart is required to complete the domain join. This can significantly reduce the overall time required for wide-scale virtual machine deployments.
A domain join establishes a trust relationship between a computer running a Windows operating system and an Active Directory® domain. This operation requires state changes to Active Directory Domain Services (AD DS) and state changes on the computer that is joining the domain. To complete a domain join in the past using previous Windows® operating systems, the computer that joined the domain had to be running and it had to have network connectivity to contact a domain controller”
I created the metadata as known as “blob” on one of my DC for a Server named 2008R2RC2 that I wanted to join to domain offline (i.e the target machine not connected to the network) and saved it to a txt file called computer_prov, then as usual I run the help on the utility to learn what syntax it has available. Here is the command syntax I ran to provision the computer account and to create the metadata.
djoin /provision /domain techevan.lab /machine 2008R2RC2 /savefile c:\computer_prov.txt
I then jumped on the target machine, copy the txt file over and try to run needed syntax with the djoin utility
djoin /requestODJ /loadfile c:\computer_prov.txt /windowspath %SystemRoot% /localos
I get an error that I am not running the Shell with elevated privileges, I get out and get back in with the “run as administrator” option, and get the same error.
Perhaps its a bug in RC release, I then tried the same syntax from the conventional CMD line window and was successful.
I then restarted the target computer and machine had been joined to the domain.
For more information please see, http://technet.microsoft.com/en-us/library/dd392267(WS.10).aspx
A couple years back someone made a recommendation on Microsoft Exchange Forums that equivalent to Exchange BPA, it would be nice for AD Admins to have an AD Best Practices Analyzer, this was passed on to the AD Team. Though I am not if this particular thread was the driver behind it, but starting in Windows Server 2008 R2, AD Admin will have the BPA.
“Active Directory Domain Services (AD DS) Best Practices Analyzer (BPA) is a server management tool that can help you implement best practices in the configuration of your Active Directory environment. AD DS BPA scans the AD DS server role as it is installed on your Windows Server 2008 R2 domain controllers, and it reports best practice violations. You can filter or exclude results from AD DS BPA reports that you do not need to see. You can also perform AD DS BPA tasks by using either the Server Manager graphical user interface (GUI) or cmdlets in the Windows PowerShell command-line interface.”
ADBPA is a great idea, it gives you a quick glance into the new DC you have just stood up. It points you toward setting the NTP settings correctly if the DC is also PDC. It lets you know if your OUs are not set to be protected from accidental deletion. It also reminds you that certain directory partitions (NC) have not been backed up since a certain of period time. You can access the ADBPA from the Server Manager -> ADDS.
You may notice that if you are running the Windows Server 2008 Beta version, there seems to be a bug with ADBPA rule. One of the non-compliant complain is about the DC’s inability to reach a DNS server to retrieve DC specific records even when the DC itself is also the DNS and the pertaining records are existing. This behavior has been corrected in the RC version.
The compliant section also shows where your DC meets the expected configuration, such as when it advertises itself as a DC in its local site. One downside I see with ADBPA is that it cannot be self-launched into its separate MMC. Or unlike the Exchange BPA, it is only accessible in a small window from within the Server Manager. So there if is large number of non-compliant/compliant messages, the browsing ability is not that great.
How does ADBPA gather this data ?
“When you run the AD DS BPA scan on a domain controller, the BPA engine invokes the AD DS BPA Windows PowerShell script that collects configuration data from the AD DS environment that this domain controller belongs to. The AD DS BPA Windows PowerShell script then saves the collected AD DS configuration data to an XML document. The BPA run-time engine validates this XML document against the XML schema.”
For more information on ADBPA. See this.
Posted: 14-05-2009 | Author: Rick | Category: Active Directory, Windows Server 2008 | No comments
It is version 47 in RC and it may very well change when R2 gets RTM. You can check the objectVersion attribute of your current forest on the Schema Naming Context (NC) via ADSIedit.msc.
Here are some older Schema versions.
13=Win2k
30=2003
31=2003R2
44=2008
Here is more detail of schema changes in Windows Server 2008 R2 RC.
http://technet.microsoft.com/en-us/library/dd378828(WS.10).aspx
Posted: 09-05-2009 | Author: Rick | Category: Active Directory | No comments
Who needs ADRAP or ADHC when you have this in front of you. This is a modification of “Good code, Bad code” by the author credited on the picture.
Posted: 01-05-2009 | Author: Rick | Category: Active Directory | No comments
Have no more than 1200 DCs in your domain..say new scalability limits.
I wonder if anyone realistically has reached that limit without a need to break down the domain into multiple domains/forest, this limitation lies in FRS’s ability to keep things sane with the SYSVOL replication. The new Active Directory Maximum Limits – Scalability recently published has very interesting pieces of information. I am highlighting below some key bullet points.
- Each domain controller in an Active Directory forest can create a little bit less than 2.15 billion objects during its lifetime.
- There is a limit of approximately 1 billion security identifiers (SIDs) over the life of a domain.
- Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately 1,015 groups.
- Fully qualified domain names (FQDNs) in Active Directory cannot exceed 64 characters in total length, including hyphens and periods (.).
- The maximum length for the name of an organizational unit (OU) is 64 characters.
- There is a limit of 999 GPOs that you can apply to a user account or computer account.
- The recommended maximum number of members in a group is 5,000. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.(Thanks to LVR).
- For Windows Server 2003, the recommended maximum number of domains when the forest functional level is set to Windows Server 2003 (also known as forest functional level 2) is 1,200.
Even though this technet-published-content puts Windows Server 2008 in context as identified in the applies to section, unfortunately details do not dive into direct scalability improvements for native Windows Server 2008 and R2 Forests. All in all even with a Windows Server 2003 forest, the limitation mentioned here are rarely to be hit in a production environment.
Creating an additional Password Policy (known as Password Settings Object) in Windows Server 2008 is very easy with QAD Cmdlets. Create a PSO with New-QADPasswordSettingsObject for example as shown below,
[PS] C:\Windows\System32>New-QADPasswordSettingsObject -name “Traders-Password-Policy” `
>> -passwordhistorylength 9 `
>> -passwordcomplexityenabled $true `
>> -minimumpasswordlength 7 `
>> -minimumpasswordage 1 `
>> -maximumpasswordage 15
>>
…
Name Type DN
---- ---- --
Traders-Password-Policy msDS-Passwor... CN=Traders-Password-Policy,CN=Password Settings Container,CN=System,D...
To check what other password’s attributes can be defined, see help for New-QADPasswordSettingsObject. The -appliesto parameter lets you define the PSO for a Group or individual user as well from right within the cmdlet shown above, but you can also do this.
[PS] C:\Windows\System32>Add-QADPasswordSettingsObjectAppliesTo ‘traders-password-policy’ -AppliesTo joe.blow
Name Type DN
---- ---- --
Joe Blow user CN=Joe Blow,OU=Users,OU=Chicago,DC=techevan,DC=lab
Unfortunately, there is no Set-QADPasswordSettingsObject cmdlet yet that lets you modify an existing PSO. You can use ADSIEDIT.msc to do that. Launch ADSIEDIT, and go to \domain node\System\Password Settings Container. Find the relevant PSO and go to its properties and make your modifications.
If you log on as the user who we just applied this PSO to in our above example, you will be notified that your password expires in 14 days. Its a great feature in Windows 7.
For more information see these links :
http://technet.microsoft.com/en-us/library/cc753481.aspx#BKMK_2
http://windowsitpro.com/article/articleid/99929/use-powershell-to-manage-fine-grained-password-policies-in-windows-server-2008.html
Posted: 29-04-2009 | Author: Rick | Category: PowerShell | No comments
Apparently there is a bug with Add-Computer cmdlet in PowerShell V2 version of Windows 7. This cmdlet according to the help (examples) allow you to join a machine to the domain. I was successful in renaming the machine with the Rename-Computer cmdlet but had issues adding the machine to the domain. Keep in mind that in Windows 7 and Windows Server 2008, you have to launch PoSH with elevated privileges, even if you are logged on as an Admin. You have to right click on the shortcut and do “run as administrator”, see screenshot 1 for the error you receive, if you don’t.
Then I take a look at the help and confirm that the syntax being passed is the right one and try with the computername,
A different error as if the credentials being password are not sufficient which is not the case as they are of Domain Admins’
While that bug gets fixed, Kirk from over at PowerGUI forums has this QAD cmdlet alternative for you as the solution.
C:\PS>new-qadObject -ParentContainer 'OU=ComputersOU,DC=company,DC=com' -type 'computer' -name 'comp1' -ObjectAttributes @{sAMAccountName='comp1'}
Lets wait for Add-QADComputertoDomain too, perhaps !
Posted: 27-04-2009 | Author: Rick | Category: Windows Server 2008 | No comments
Posted: 21-04-2009 | Author: Rick | Category: Hyper-V, Windows Server 2008 | No comments
As expected, and just like its counterpart you can’t run guest OS, (child partitions) within Hyper-V when Hyper-V itself is installed as a guest VM. Of course there are several tweaks out there that let you modify VMkernel and supposedly let you run guest VMs in ESX environment. I have yet to come across one that does the trick for Hyper-V. Perhaps its not possible due to some substantial differences how hypervisor of Hyper-V is different than hypervisor of ESX(i) that of VMware. Greg Sheilds recently wrote in length regarding correctly explaining the difference between two products.
Rich Brambley on the other hand installed Hyper-V R2 under VMware Workstation but didn’t proceed to install VM as a guest on it, which in my opinion was against the whole purpose. You can’t really begin to play around with its feature set until you have a hand full of workloads running on it.
I gave it a spin, and I came across the “No, No, you can’t do this” issue. I have Hyper-V R2 installed as a guest on VMware Workstation 6.5.2. As posted in last post, Hyper-V is being managed via Windows Server 2008’s Hyper-V Management feature.
Posted: 19-04-2009 | Author: Rick | Category: Hyper-V, Server Core | No comments
Ever since Microsoft joined VMware in handing out their introductory type-1 hypervisor solutions (without management software) out for FREE, there is a fair share of confusion in IT community regarding the standalone Hyper-V. Hyper-V is a standalone product that will run on a bare-metal box and will need to be managed via Windows Server 2008 Hyper-V Management (feature). Hyper-V is built on Windows Server 2008 Server Core and Windows Admins will find it easy to adjust to managing it. Especially those who have had experience with Server Core.
I wrote a few posts earlier on managing Server Core, regarding the initial configuration, opening the needed ports thru firewall, network configuration etc. You will find that there is another layer of managment window on top of that CLI window you are used to seeing in Server Core. That window is there for you to manage the Hyper-V.
As you log in to Hyper-V both windows the CLI and Hyper-V Configuration pop up, with first one in the background. On Hyper-V configuration window, there is 16 options (sub-menu) that are pretty self explanatory and allow you to setup initial configurations such as adding the server to domain, configuring NIC, enabling RDP, and remote management (WinRM) and so forth.
Remember that with the substantial feedback from IT pros, this new version of Server Core (that Hyper-V is built upon) now has the limited .NET layer added which will make the server management easier but as expected it adds to its size to its previous versions. This is of course only part of recently released Hyper-V R2.
Here are some screenshots of Hyper-V R2.
