Home » Posts tagged 'active directory'

Tag Archives: active directory

Save those service accounts!

Have you ever woken up at 2:33 am to the phone ringing off the hook because some service is not longer running and it must be fixed right now? And this service not running is because someone reset the password on a service account last week? I’ve seen this scenario play out way more than it ever should. Let’s nip that problem of service accounts running wild right away.

Checks all servers available in the domain for services running under service
Find-AllServiceAccounts grabs a list of all servers from the current domain and
uses WMI calls to retrieve a list of services from the servers. It then loops
through the services checking for service accounts and writes any service
accounts found to a CSV specifically for that server.
You will be prompted for credentials when first running this.
Import-Module ActiveDirectory
# Default system accounts to exclude
$ExcludedServices = "NT AUTHORITY\LocalService", "LocalSystem", "NT AUTHORITY\NETWORK SERVICE", "NT AUTHORITY\NetworkService"

# Will pop up a prompt to provide credentials for making WMI calls
# to the remote systems
$Credentials = Get-Credential

# Uses the LDAP search results for computers
$HostList = Get-ADObject -SearchBase (Get-ADRootDSE).defaultNamingContext -LDAPFilter "(&(objectCategory=computer)(|(operatingSystem=Windows Server*)(operatingSystem=Windows 2000 Server)))" -Properties Name
$HostName = Get-Content env:computername

# Pass a service name in and check to see if it matches the excluded
# service accounts that you've preconfigured
function Check-ServiceName($ThisServiceName)
Check-ServiceName verifies if a service is not a default service account
Check-ServiceName checks the service account for the specified service against
the list of excluded services from the $ExcludedServices variable. Returns $true
or $false.
.PARAMETER ThisServiceName
The service account to be checked against.
  foreach($ExcludedName in $ExcludedServices)
     if($ThisServiceName -eq $ExcludedName.ToLower())
       return $true
  return $false

[array]$BadHostList = $null
# Our main loop, iterates through each system listed in
# the file and pulls all of their services
foreach($HostServer in $HostList)
  # Grab the list of services from the system
  if ($HostServer.Name -ne $HostName)
    $ServiceList = get-WMIObject -Class win32_service -ComputerName $HostServer.name -Credential $Credentials -Property name,startname
  # If it is the localhost then we need to exclude the credentials parameter
    $ServiceList = get-WMIObject -Class win32_service -ComputerName $HostServer.name -Property name,startname

  # If the host could be contacted, loop through and check each service
    [array]$CSVArray = $null

    foreach($ThisService in $ServiceList)
      $CheckResult = Check-ServiceName($ThisService.StartName.ToLower())
      if ($CheckResult -eq $false)
        Write-Host "Service: " $ThisService.name
        Write-Host "Account: " $ThisService.StartName
        $CSVArray += ,$ThisService | select Name,StartName    

    if ($CSVArray.count -gt 0)
      Write-Host "Saving .csv for $HostServer"
      Write-Host ""
      $CSVArray | Export-CSV "$HostServer.csv"
  # The host could not be contacted, note it down
    Write-Host "$($HostServer.name) is unreachable."
    $BadHostList += $HostServer

if($CSVCount -gt 1)
  Write-Host "Done, wrote out $($CSVCount) .csv files."
elseif($CSVCount -eq 1)
  Write-Host "Done, wrote out $($CSVCount) .csv file."
  Write-Host "No .csv files written out, no service accounts found."

  foreach($TargetHost in $BadHostList)
    Write-Host "$($TargetHost.Name) at $($TargetHost.DistinguishedName) was unreachable."

What this does for you is that it runs through all of your servers (assuming they will respond to WMI queries, you’ll want to check your firewall policies) and dumps out a CSV for any server with service accounts reporting what services are using service accounts and which service accounts those are. This will save you much frustration in tracking down who will be impacted by a service account password reset, security audits, password reset frenzies and just plain documentation.

Speaking of security audits and password resets, in an upcoming post I’ll show you how to easily update all of your service account passwords so that you can spend the rest of the day playing Animal Crossing rather than remoting from server to server to server …

Did this post help you out? Do you have any questions or a specific topic you’d like me to delve into? Just let me know, thanks!

OWA Login – Your Account has been Disabled

While this may not be a common issue, or at least I certainly hope it is not a common issue for you, it can be a bit vexing to figure out what is going on. You have a user with a recently restored account that is attempting to login to OWA and they are receiving an error similar to the following:

Your account has been disabled.

Copy error details to clipboard

Show details


Url: https://mail.contoso.com:443/owa/

User host address:

User: Jane Doe

EX Address: /o=first organization/ou=exchange administrative group
(fydibohf23spdlt)/cn=recipients/cn=jane doe96d

SMTP Address: jdoe@contoso.com

OWA version: 14.2.318.2

The steps leading up to this error are most likely as follows.

  1. A user’s account was deleted and their mailbox removed recently. Possibly by accident or possibly by company politics.
  2. The user’s account is recreated as opposed to restored (which means a new SID and all the fun that goes along with that) and their mailbox is reattached to the account.
  3. The user now attempts to login with their “new” account into their old mailbox.
  4. Angry calls to your help desk now ensue.

Most likely your first thought was to do an iisreset but in this case you would be wrong. Here is how you clear this issue up swiftly and easily. Open up the EMS and run:

Clean-MailboxDatabase –Identity <Database Name>

This kicks off a scan of AD that updates the status of disconnected mailboxes in the targeted database. Alternatively you could also just tell the user to wait until Exchange runs its maintenance cycle on the database but that answer definitely won’t win you any friends. Now why does this need to be done? As you’ve probably suspected it is due to cached AD information of the disconnected mailboxes. For more info take a look at KB2682047.

Active Directory Internal Naming and DNS Strategy

This post touches on something that is rather simple, yet I’ve seen it done improperly at many of the SMB clients that I work with by a previous provider. This has resulted in some unnecessary complexity and even migrations to a new forest to meet requirements such as for Exchange 2007 when it did not support single label domains. When you are first creating your Active Directory forest you want to put some thought into what you are naming it. You need to first think about the company’s internet facing domain names and what sort of traffic is being generated through them. This changes your DNS strategy depending upon, for instance, if the company’s website is being hosted by the company or if it is hosted by a third party. You will also need to think about where your public DNS is being served from. Another thing to throw into the mix is security, which ties into the previous issue. Let’s take a look at a few things here.

Microsoft has some best practices guidelines here. My personal preference is to go for a non-registered TLD such as .internal or .local so as to provide no confusion with TLDs such as .com or .net. Microsoft would prefer for you to go with a subdomain of your external domain i.e. corporate.contoso.com for your AD forest while using contoso.com on the internet facing side. Either way of doing it a benefit you reap is that name resolution for contoso.com is done externally. The reason for this is that while your internal DNS is authoritative for contoso.local or corporate.contoso.com it is not authoritative for contoso.com itself so it will find a server that is. This will return the internet facing IP address for whatever is in contoso.com. The reason you would want this is because, especially for the majority of SMBs that I work with, most often their website is hosted at a 3rd party provider. If your AD forest was contoso.com that would add complexity as you would have to manage internet addresses both internally and externally as you would no longer be able to forward requests to your public DNS provider. For example for the record of http://www.contoso.com if you switched 3rd party hosting providers you would need to update that A record on your public DNS. You would also need to update that record internally, otherwise the next day your client will be calling in to let you know that their website is “down.”

Now what if you were hosting your own DNS? For security you would want to put your public DNS into your DMZ serving different zones than your private DNS servers. The reason for this is to restrict public access to your internal DNS hierarchy. Access to that would give hackers a huge amount of information on your internal network such as naming conventions, internal ip addressing and even names of your DCs. Your private DNS would then forward requests for contoso.com to your public DNS and management is simplified since internal changes would not affect external changes and vice versa.

Next obstacle to face is what if you were hosting some addresses internally but others are hosted at a 3rd party, such as www .contoso.com goes to your company’s website but mail.contoso.com goes to your OWA. Creation of a zone internally for that specific address would allow internal requests to be managed by your internal DNS while still forwarding requests for the company site to the public DNS side. This simplifies DNS management as well. You would have your mail.contoso.com zone and you could be migrating from one Exchange server to another and all you would have to manage internally is the mail.contoso.com zone. Your public IP address has not changed at all so your public A record for mail.contoso.com has no need to be updated. All those remote users hitting mail.contoso.com would not notice a difference, unless of course you have forgotten to change your NAT and firewall rules but that is an entirely different subject. Also if the reverse is true and you are changing your public IP address you would still only be changing your public DNS records. Private DNS would not be impacted whatsoever.

So what if you were to go with contoso.com for your AD forest as well as your public DNS? DNS changes would be more complex. You would need to manage addresses both externally and internally. An example, you have your mail.contoso.com address created externally and your remote users are using OWA. If they come into the office suddenly all their OWA requests are failing since an A record internally is not created. You create your A record pointed to your Exchange server internally and everything works properly again. Then there is the scenario of the company website which is hosted by a third party. Users are able to access http://www.contoso.com outside the company but inside the company the requests fail. You create an A record pointed to the 3rd party site and everything works again, until you switch your hosting provider. People will be unable to access the site again until you also update the internal DNS record.

There is also the single label domain name to think about. Microsoft recommends to avoid this and I would also recommend avoiding it since it requires even more initial management to get things working properly. It can also cause problems with cross forest trusts.

Keep your DNS simple and you will have less late nights trying to figure out why mail.contoso.com does not work on the company network.

Manually Connecting Mailboxes by MailboxGUID or Hey! Where did my mailboxes go?!

On Monday I learned the hard lesson of always making sure that your Active Directory is replicating properly, especially in the middle of a migration. At least this is the best explanation that I can come up with for what happened. We were wrapping up my first Small Business Server 2003 to SBS 2008 migration, with an already less than stellar performance due to the Exchange System Manager refusing to show the new server, and to a few mailboxes that refused to move over. We had to export those monstrosities to pst before we could move them over. Which turned into a mixed blessing later on. Things had come to the point of being ready to remove Exchange 2003 from the SBS 2003 server, which went along fairly smoothly. We rebooted the server ready to breathe a sigh of relief that this portion of the migration was done. Not so lucky, the true nightmare began then. The calls from the users began coming in that they could no longer access their email, even after confirming that they really were pointing to the new server. I fired up the Exchange Management console to find out what was wrong to discover that no mail enabled users showed up, aside from the three we had to import from pst. I took a look for disconnected mailboxes and to my horror we did not have any. Restoring from backup wasn’t an option as we had not been able to take one yet. This began a mostly fruitless 6 hour call with Microsoft. It is very sad when your bluetooth dies and you also are able to recharge it and start using it again during the same call. Fortunately I did not stop doing research into the problem while on the call and eventually cobbled together the solution that I am going to present to you now. My warning is – do NOT do it this way unless you absolutely have to.

Before I had made the call I ran a Get-MailboxStatistics. Interestingly this reported everyone’s mailbox as existing and containing data. This meant that the users had lost their Exchange attributes. To verify this required digging into Active Directory with ADSI edit. Open up ADSI edit and connect to the default view. Drill down to the OU of your user and pull up their properties. You will see a list of attributes set there. Some specific attributes are required to mail enable a user. legacyExchangeDN, homeMTA, mailNickname,  msExchHomeServerName, and finally as well as perhaps the most import is msExchMailboxGuid. homeMDB is required as well but fortunately this was still populated. On the users that were missing mailboxes none of the msExch attributes were set. Fortunately there did remain some users, so looking at those I was able to glean a few of the attributes.

legacyExchangeDN –This attribute needs to be configured to point to the login for your mail enabled user. This drills down through the organization name and the default administrative group name ending down in your user’s login name. Example:  /o=first organization/ou=exchange administrative group (fydibohf23spdlt)/cn=recipients/cn=jland

You can pull this information from your mailboxes actually. Run Get-MailboxStatistics | ft Displayname, LegacyDN

homeMTA – This may not be required under Exchange 2007, but we decided to set it none-the-less. This drills down through Active Directory to where your Exchange server’s MTA resides. Example: CN=Microsoft MTA,CN=SERVER,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=linthicum,DC=local

mailNickname – This one is easy to miss yet is very important. If you user still doesn’t show up as mail enabled go back and make sure you entered in the mailNickname. This generally would be your user’s login name, though you should consult your organization’s naming scheme to be sure.

msExchHomeServerName – This one is fairly self-descriptive. This points to where your server is located in Active Directory, as based off the organization name. An example is: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=SERVER

msExchMailboxGuid – This one is the kicker. Exchange won’t know what mailbox to connect your user to without this info. But it isn’t exactly easy to get ahold of either. First run Get-MailboxStatistics | ft Displayname, MailboxGUID. You’ll see everyone’s msExchMailboxGuid listed right there. Easy? No. Now you have to be able to get that into Active Directory. Which is a royal pain. Go down through the properties of your user and open up msExchMailboxGuid to put in some new information. See how you only have the options of decimal, hex, octal and binary? You need to convert this GUID into something usable.

Go to joeware’s great site and download the adfind tool.  Open up a command line and go to where you extracted the tool and run adfind -gc -b “” -binenc -f ” msExchMailboxGUID={{GUID:98ee00d7-df19-4282-bedf-3a1340b8b7c0}}” –dn where of course you replace the GUID with the one you are searching for.  This will return you some interesting output which still isn’t quite usable, though it may look that way at first glance. Your response is mostly hex, but not fully. You need to translate it. I’ve included a utility at the bottom of this post that you can use to convert this output into full hex. Pull up the table at Ascii Table and use this for your translation. Start going through the characters and when you find one that doesn’t match like for instance a lower case j or the number 4 unpaired, look through the red characters in the table for your character and you’ll see the conversion to hex in the separate column. Go through the whole string this way and you’ll eventually get a fully hex string. Go back into your msExchMailboxGUID and put that in and after you click ok you’ll see that the attribute has been populated with the string that you began with. Look very closely at it to make sure it matches. If there’s some deviation go back and check your look-up tables again. This string should match completely, otherwise your user will end up with an empty mailbox created. Here’s an example of how to convert the returned string:


D7 00 EE 98 19 DF 82 42 BE DF 3A 13 40 B8 B7 C0

And another one:


54 BA A0 34 6C B8 EE 4D 9F D6 40 6D 25 08 CE A0

Your user has now been mail enabled as a refresh of your Exchange Management Console will show, but is still missing a number of Exchange attributes. Run Set-Mailbox “My User” –ApplyMandatoryProperties and all the rest will be filled out for you.

The last bit is to clean up Outlook for your users. Even the ones not using Cached Mode still showed as disconnected until we re-put the server back into their profile. For the ones using Cached Mode it was also a good idea to delete their .oab files from their directory to force them to download a newly rebuilt OAB. This may or may not be necessary in your case as that was most likely related to the timing in the migration. If you didn’t delete them it would populate the DN to the user they’re emailing rather than the email address, thusly bouncing back to them when they emailed.

Some extra reading:

Understanding Mailbox GUIDs

How to Re-Home Exchange Mailbox Accounts

Using ADFind Utility


I’ve finally gotten around to writing a simple little utility for converting the resulting GUID output from adfind into full hex for pasting back into adsiedit. Usage is guidconvert.exe <adfind guid output>.  Here’s the utility. C# source has been included as well.

Building Your Fortress with RODCs on Core

Now for the topic that you all have been waiting for. Building an RODC! Read only domain controllers are another one of those awesome additions to Server 2008. An RODC holds read only copies of parts of your AD. They’re ideal for branch offices or even your DMZ where you need heightened security but also still need access to your AD as well. RODCs don’t contain a copy of your credentials but only caches those that you set as per policy. In cases of customized AD-integrated applications you can also mark certain attributes in your AD as filtered. Filtered attributes do not replicate to an RODC, so if the RODC is ever compromised the attacker will not gain this critical information. Furthermore any changes made on an RODC do not replicate back out. If for instance someone makes some changes to the SYSVOL folder, those changes will not replicate out to all the other DCs in the forest. It will make that SYSVOL out of sync with the rest of the forest though and could cause some Group Policy idiosyncrasies. If you are using DFS replication for SYSVOL though this problem is fixed automatically. Later I may talk about how to enable DFS-R.

As a side note, anyone running VirtualBox under Linux and has switched to the newly released 2.6.29 kernel may be having a bit of trouble with their VB installation. If you are receiving an error message like this when starting a VM:

Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND).
Unknown error creating VM (VERR_SYMBOL_NOT_FOUND).

Then you are in need of editing the vboxdrv Makefile. You should find this in /usr/src/vboxdrv-2.1.4/Makefile. You might need to tweak the version number depending upon your installed version. Uncomment the line # VBOX_USE_INSERT_PAGE = 1. Re-run your /etc/init.d/vboxdrv setup command under your root account (or just use sudo) and you should be good to go. More information about this is available here.

Let’s get a new VM created that we will be purposing for our RODC. Get it installed and joined to the domain, but we’ll be building a different answer file for the dcpromo. One important thing to remember by the way, for practical as well as testing purposes, is that to install an RODC requires a minimum forest functional level of Server 2003. Also for testing and practical purposes remember you only need one DC in your domain running Server 2008. No need to migrate over all your DCs yet. You also have to prep your forest. Login as an Enterprise Admin on your schema master, mount your Server 2008 DVD, and run:

C:\>mkdir C:\adprep
D:\>xcopy /E D:\sources\adprep C:\adprep
C:\>cd adprep
C:\adprep>adprep /rodcprep

This copies over adprep files and then preps the forest DNS partitions for replication to an RODC. Now to set up your answer file:


You will also want to specify ReplicationSourceDC= if you have Server 2003 DCs and need to point to your Server 2008 DC. You can also specify PasswordReplicationDenied to deny any additional users/groups replication to this RODC. Once you have your file created run the dcpromo as normal.

C:\>dcpromo /unattend:install.txt

Upon success restart your RODC. If you have your site set up properly they should now be able to log into their systems with authentication through the RODC. Now to do some delving into management of your RODC specifically dealing with the Password Replication Policy (PRP). This is what defines what credentials will be cached and what will never be cached. What happens in the case of a denied password caching the RODC forwards the request on up the WAN to a writable DC for authentication. To view what is currently set for your RODC run:

C:\>repadmin /prp view JenovaCoreRODC allow
C:\>repadmin /prp view JenovaCoreRODC deny

This will show you what is currently allowed and denied for the RODC you have specified.

C:\>repadmin /prp view JenovaCoreRODC auth2

From this you will view all accounts that have been authenticated by this RODC. Finally to know what credentials have been cached by the RODC run:

C:\>repadmin /prp view JenovaCoreRODC reveal

It is important to know what credentials have been cached in case of the RODC being compromised. Now if you are wanting to update the list of what accounts you wish to allow caching for then run:

C:\>repadmin /prp add JenovaCoreRODC allow “CN=Lab Guests,OU=Lab Users,DC=shinra,DC=inc”

This uses the LDAP DN to the account or group that you wish to allow caching for. Something to remember is that an account won’t actually be cached until they have logged in authenticating to that RODC. You can pre-populate credentials via this command:

C:\>repadmin /rodcpwdrepl JenovaCoreRODC CloudCore “CN=Jeffery Land,OU=Lab Users,DC=shinra,DC=inc” “CN=Jeffery Land2,OU=Lab Users,DC=shinra,DC=inc”

You can specify as many users as you would like separated by a space. You will have to specify user accounts and not groups though. Most likely you would want to script this if you’re pre-populating an RODC for a site with limited/sporadic WAN connectivity. Remember that you not only want to allow caching for user accounts but also for any computer and service accounts that require authentication. Otherwise the RODC will attempt to forward the authentication on up and if the WAN is down it will fail due to not having a cached account. You are best off first working with an RODC in a lab environment prior to deployment so that you have worked through all such issues that could arise. Also if an account is both in the allowed and denied lists the account will be denied caching as deny takes precedence.

This should get you up to speed on RODC installation and management. Here is some reading for you to more thoroughly understand RODC implementation and management.

Read Only Domain Controllers
RODC Planning and Deployment
RODC FAS, Credential Caching, and Authentication
RODC Administration

A Sidetrip to Linux with Active Directory

This is a temporary detour into the land of joining a Linux server to your Active Directory. This was one of my first experiences working with Linux on the job so it was quite exciting how there was almost no documentation on how to do this at the time, and what was out there didn’t work quite right or not at all. It took me a while but I eventually got it working. Since there are so many flavors of Linux out there the same methods may or may not work for you. The machine being joined is running CentOS 5.2 with a fresh install.

As always before you start setting this up make sure that your network configuration is set just fine, that you can ping everything and name resolution works. Don’t forget to add an A record for your linux machine. The first thing you need to do is get your kerberos config set up, and set up properly. The majority of the time if something breaks it will be in your kerberos configuration, since the krb config is rather fragile. Open up your /etc/krb5.conf and edit it to look similar to what is below. Remember that the capitalization is extremely important as well as punctuation.

default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

default_realm = SHINRA.INC
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes

kdc = cloudcore.shinra.inc:88
admin_server = cloudcore.shinra.inc:749
default_domain = shinra.inc

.shinra.inc= SHINRA.INC
shinra.inc = SHINRA.INC

Once you have that set up run

kinit administrator

If no errors are returned after entering in your password that should (but not always) mean that your kerberos set up is working fine. Run klist to make sure you have a kerberos ticket. Next up is configuring samba. Edit your /etc/samba/smb.conf file as follows.

workgroup = SHINRA
realm = SHINRA
netbios name = LINUXTEST
security = ads
password server = cloudcore.shinra.inc
domain master = no
idmap uid = 1000-29999
idmap gid = 1000-29999
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
winbind refresh tickets = true

Then edit your /etc/nsswitch.conf as follows.

passwd: files winbind
shadow: files winbind
group: files winbind
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files winbind
rpc: files winbind
services: files
netgroup: nisplus winbind
publickey: nisplus
automount: files nisplus winbind
aliases: files nisplus

The important part is adding winbind. Your nsswitch.conf may be customized to your network. Now the final file for you to edit /etc/pam.d/system-auth. Look for a line similar to auth sufficient pam_winbind.so and edit it as follows.

auth sufficient pam_winbind.so krb5_auth krb5_ccache use_first_pass

Now we should have everything configured so let’s start things up and get joined to our AD. First we need to set things to auto start and then we’ll start the services.

chkconfig –level 35 smb on
chkconfig –level 35 winbind on
/etc/init.d/smb stop
/etc/init.d/winbind stop
/etc/init.d/winbind start
/etc/init.d/smb start

Next up is joining the domain.

net ads join -U administrator

This should run successfully. To test and make sure you are joined run wbinfo -u and wbinfo -g. These should list the users and groups respectively in your domain. Now you should be set. I’ll go over a few errors that I’ve encountered and possible solutions. It is a touchy process so if this didn’t work for you it may just require a bit of tweaking for your flavor of Linux and your own AD.

Some possible errors you may encounter.

When attempting net ads join -U administrator I get the error:
Host is not configured as a member server.

Check your smb.conf for errors. Make sure that you set security = ads. Run a testparm to make sure you don’t have other configuration errors.

When attempting net ads join -U administrator I get the error:
[2009/03/11 09:55:32, 0] libads/kerberos.c:create_local_private_krb5_conf_
for_domain(594) create_local_private_krb5_conf_for_domain:
failed to create directory /var/cache/samba/smb_krb5.
Error was Permission denied

Manually create the directory /var/cache/samba/smb_krb5. It may be an issue related to using SELinux. I haven’t researched into it enough to determine a proper work around.

My net ads join -U administrator works but wbinfo -u and wbinfo -g are still returning errors.

Make sure your winbind service is running. It is generally best to start winbind before starting smb in my experience.

New Forest on Server 2008 Core

Now that we’ve got our virtualization platform in place it is time to start building our network. We’ll start off with one of the great new features of Server 2008. Server 2008 comes in 2 different flavours, in addition to picking Standard, Enterprise and Datacenter. First off is your regular Full version of Server 2008. You get your GUI and everything else with that. Then comes Core. Core is a stripped down version of Server 2008 that is managed from the CLI. There are only a couple of GUI elements left. This version also takes up far disk space and memory than the Full version. It requires only 100 megabytes for the kernel and then you just start adding on for the services you start building in. Core is primarily intended for a low resource box that runs a few of the core services for an Active Directory based network. Core also has a reduced attack surface due to being so stripped down. Not all roles and features available under Full are available in Core. A few important ones missing are Terminal Services, NAP, and AD CS. IIS is available but without ASP.NET. For the features one of the biggest missing is the .NET Framework which means, sadly, that no PowerShell is available on Core. Core will still accept remote WMI queries though so you will still be able to use PowerShell to execute WMI queries remotely. Though apparently it is possible to hack it in. I have not tried this yet though. So now that we know a bit about Core, let’s use this to set up our first forest.

Boot off the dvd and make sure that you select Core. For our first DC we don’t really need the extra features of Enterprise so I would recommend Standard. Installation is pretty simple so just run the rest of the way through and login setting your admin password. Now the first thing we have to do is get your network configured. I am working with 10.60.0.x but it is up to you to decide your ip block. We will start off with the netsh command.

netsh interface>ipv4
netsh interface ipv4>show interfaces

The results will list all of your connections giving you in the first column the index number. Look up your network connection as that is the one that we will be working with.

netsh interface ipv4>set address name=”2” source=static address= mask=

You can also add a gateway=x.x.x.x parameter to configure your gateway if necessary. Since this network is just for testing purposes I have no need for gateway currently. Also note that the name is the index number of the nic you are working with. If no errors are returned then the command should be successful so type quit and then just to be sure do an ipconfig /all. You should see your new settings listed. Now let’s get the name set for this machine.

C:\>netdom renamecomputer %computername% /NewName:CloudCore

Agree to proceed and then we’ll need to reboot the machine.

C:\>shutdown /r /t 0

This issues an immediate reboot of the machine. Don’t forget that if you’re confused about a command you can issue the command with a /? to find out more information about it. Now that we have our network connection let’s get Active Directory set up. This gets a bit more complicated than configuring your network but if you are at all familiar with unattended installations then you won’t have too much difficulty.

C:\>notepad unattend.txt

Core still has our trusty notepad application. Here is a copy of the config we will write up for doing an installation of AD DS on this machine.

ReplicaOrNewDomain = Domain
NewDomain = Forest
NewDomainDNSName = shinra.inc
SiteName = Shinra-Headquarters
ForestLevel = 3
AutoConfigDNS = Yes
DNSDelegation = Yes
DNSDelegationUserName = dnsuser
DNSDelegationPassword = Pass1word
RebootOnSuccess = Yes
SafeModeAdminPassword = Pass1word

It should be pretty self explanatory but I will go over a few options here. If you want to see more options and find out more about these current options use dcpromo /? and/or dcpromo /?:Promotion. Now the NewDomainDNSName is what you are wanting to use for your new forest. It is best practices not to use your public DNS name for your internal Active Directory structure. Most people like to use a postfix of .local but you can use whatever you want. An example using mine here is if my external DNS was shinra.com then using shinra.inc would be a good choice for the internal AD structure. The SiteName is not necessary as it will default to Default-First-Site-Name but I dislike using such a nondescript name. ForestLevel will set your forest to a particular level. The default is Windows 2000 but using 2 will set to 2003 and 3 to 2008. Be careful when setting your forest level as you can’t go back. Since we’re starting from scratch here it is ok to go with a 2008 forest level. Once we start introducing some RODCs you will need a forest level of 2003. The domain level is automatically set from the forest level in this install.

Now we’re ready to run through those so execute

C:\>dcpromo /unattend:unattend.txt

If all is well you should see the installation run through and it will reboot at the end, if you left the RebootOnSuccess flag set. There you go you have your first Active Directory set up, and on Core none-the-less! So here are a few tasks few you to go about for some good practice. Add a second DC, preferably on Core. Make sure to put a global catalog on it too. Create yourself an OU and put in a standard user account for yourself to use there as well. You could even try writing a script to pre-populate a large number of users. The commands you’ll want to check out for this are dsadd and dsmod. Up next we’ll get into installing and configuring DHCP.

%d bloggers like this: