Posts Tagged ‘windows 7’

Creating a binding script to join Windows 7 clients to Active Directory

Tuesday, July 3rd, 2012

There are some different ways to join Windows 7 to a domain.  You can do it manually, use djoin.exe to do it offline, use powershell, or use netdom.exe.

  • Doing so manually can get cumbersome when you have a lot of different computers to do it on.
  • With Djoin.exe you will have to run it on a member computer already joined to the domain for EACH computer you want to join since it will create a computer object in AD for each computer before hand.
  • Powershell is OK to use, but you have to set the script to unrestricted before hand on EACH computer.
  • Netdom is the way to go since you prep once for the domain, then run the script with Administrator privledges on whatever computers you want to join on the domain.  Netdom doesn’t come on most versions of Windows 7 by default.  There are two versions of netdom.exe, one for x86 and one for x64.  You can obtain netdom.exe by installing Remote Server Administration Tools (RSAT) for Windows 7, and then copying netdom.exe to a share.

A quick way to deal with both x86 and x64 architectures in the same domain would be to make two scripts.  One for x86 and one for x64 and have the appropriate netdom.exe in two different spots \\server\share\x86\ and \\server\share\x64\.

You’ll need to either grab netdom.exe from a version of windows 7 that already has it, or you’ll need to install RSAT for either x64 or x86 Windows 7 from here:, which ever you will be working with.  Install that on a staging computer.   The following steps are how to get netdom.exe from the RSAT installation.

  1. Download and install RSAT for either x64 or x86.
  2. Follow the help file that opens after install for enabling features.
  3. Enable the following feature: Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tools > AD DS Tools > AD DS Snap-ins and Command-Line Tools

netdom.exe will now be under C:\windows\system32

Create a share readable by everybody on the domain, and drop netdom.exe there.

Create a script with the following (From:

@echo off
SET netdomPath=c:\windows\system32
CALL BATCH.BAT %adminUser%
SET sourcePath=\\fileshare\folder\

::If necessary, copy netdom to the local machine
IF EXIST c:\windows\system32\netdom.exe goto join
COPY %sourcePath%netdom.exe %netdomPath%
COPY %sourcePath%dsquery.exe %netdomPath%
COPY %sourcePath%dsrm.exe %netdomPath%

::Join PC to the domain
NETDOM JOIN %computerName% /d:%domain% /UD:%adminUser% /PD:%passwd%

SHUTDOWN -r -t 0

Change domain and sourcepath to their real places.  Remove dsquery.exe and dsrm.exe if not needed.  If you’re just joining a domain, and not running anything after, then you don’t need them.

Create another script called “BATCH.BAT” that will hold your credentials that have access to joining computers to the domain.  Put BATCH.BAT in both places that house your Join-To-Domain script (…/x86 and …/x64)

@echo off
SET passwd=thisismypassword
SET adminuser=thisismyadminusername

  1. Ensure you have the scripts in the same directory.
  2. Open up a command prompt with Administrator privledges and change directory to the location of your scripts.

Runnning the first script will:

  1. Run a check to see if netdom, dsquery, and dsrm are installed under system32, if they are, it will then join the domain, if not it will attempt to download them from your share.
  2. Once it ensures it has the files it needs, it will join the computer to the domain under the “Computers” OU with its current computer name using the credentials set by BATCH.BAT.
  3. It will reboot when done.

This will work on both Server 2003 and Server 2008.

Support for Windows XP and Office 2003 Ending

Monday, April 9th, 2012

Microsoft has announced an official end to support for Windows XP and Office 2003 on April 8, 2014. This means no security updates, fixes or even paid assistance for fleets of XP systems that still dominate enterprise environments. While there have been announcements that XP support is going away, Microsoft has continued to extend it until now. At this point, the products will be over 10 years old. The return on investment of the combination has been as good as any combination throughout the history of large scale IT deployments.

If you are still using Windows XP, 318 can work with you to migrate from Windows XP to Windows 7 or plan a migration to Windows 8 when it is available to the public. For assistance with such migrations, contact your 318 Professional Services Manager, or if you do not yet have one.

Windows Firewall via GPO

Monday, March 12th, 2012

Setting up the Windows Firewall to run on Windows client systems can be tedious when done en masse. But using a Group Policy (GPO) to centrally manage systems can be a fairly straight forward process. First, decide which firewall rules you want to implement. Then, manually configure them and test them  out on a workstation to verify it works the way you want it to. This process has been documented at

Once you know the exact settings you’d like to deploy, create an Organizational Unit and put computer accounts (or other OUs/security groups) to be governed by this policy in the new OU. Once you have all of your objects where you’d like them, it’s time to create a GPO of the settings (which should be applied to one machine and tested before going wide across a large contingent of systems). To do so, go to the policy server and Features from within Server Manager to expand Group Policy Management.

From Group Policy Management, expand the appropriate Forest and Domain and then right-click Group Policy Objects, clicking New at the contextual menu. Then provide a name for the new GPO (e.g. Windows Firewall Policy) and click on OK. In the Group Policy Management screen, click on Group Policy Objects and then right-click on Firewall Settings for Windows Clients. Click on Edit to bring up the Group Policy Management Editor.

At the Group Policy Management Editor, right-click Firewall Settings for Windows Clients policy, and select its Properties. Click on the Disable User Configuration settings check box and at the Confirm Disable dialog box, click on the Yes button and click OK when prompted.

In the Group Policy Management Editor open Policies from Computer Configuration. Then expand on Windows Settings and then on Security Settings and finally Windows Firewall with Advanced Security. Here, click on Windows Firewall with Advanced Security for the LDAP GUID for your domain. Then open Overview to verify that each network location profile lists the Windows Firewall state as not configured.

Click on Windows Firewall Properties and under the Domain Profile tab, use the drop-down list to set the Firewall state to On. Then, click on OK and verify the Windows Firewall is listed as On.

Once you’ve created the GPO, go to the OU and click on Link an Existing GPO. Here (the list of GPOs), select the new GPO and test it on a client by running gpupdate or rebooting the client. To verify that the GPO was applied, open the Windows Firewall with Advanced Security snap-in and right-click on Windows Firewall with Advanced Security on Local Computer, selecting Properties from the contextual menu. If the setting is listed as On then the policy was created properly!

NetBook Upgrades for Windows 7

Monday, October 26th, 2009

Chances are that if you have a NetBook you don’t have a DVD drive. And chances are if that NetBook is running a previous version of Windows that you’re probably thinking about upgrading it to Windows 7. If you are using a NetBook with Vista then you might want to check out the new Windows 7 USB/DVD Download Tool. With the Download Tool you would use a 4GB USB drive to cache the installer files and install Windows 7. Therefore you wouldn’t need an optical drive! But you will need the .NET Framework 2.0 or later and to configure the BIOS to boot off the jump drive.

Happy upgrades and if you need any help, as always, feel free to call 318.

Windows 7 Officially Available

Thursday, October 22nd, 2009

Windows 7 has been released officially released. You see the wacky people standing in line and you know that’s just wrong when you can get it on as an immediate download All that time spent driving home could instead be spent running the installer and crossing your fingers that your hardware works! Well, if you’re going from XP or Vista then you should be fine on that point… Windows 3.1, maybe not so much…

Add Copy To and Move To Contextual Menus in Windows 7

Tuesday, May 5th, 2009

As with XP and Vista, Windows 7 doesn’t have the uber-useful (to us at least) Move To and Copy To options in the contextual menu’s by default. To create a Copy To menu item, go to the HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers location in the registry and create a new Default key with a name of Copy To and a value of {C2FBB630-2971-11D1-A18C-00C04FD75D13}. To create a Move To menu item, go to HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers (the same location) and add a new Default key with a name of Move To and a value of {C2FBB631-2971-11D1-A18C-00C04FD75D13}. Now you should have the menu items. Notice that the keys are only different in the 30 at the end of the first string of hex numbers…