In one such case, I could log into the domain controller with an administrative account in the domain of the domain controller.  However, when trying to log into the domain controller with a account from a trusted domain, I kept getting the same error message and denied logon.  The domain controller is hosted off-site in another timezone.

I made sure both domain controllers were synchronised correctly, manually corrected the time (which was already synchronous) and even rebooted the faulty domain controller.

It was only until I went to check the Timezone settings that I found something peculiar: the time zone settings indicated that the location was 3 hours ahead of GMT, while my location was 1 hour ahead.  And still, the difference between my location’s time and the culprit’s location was only one hour.

Again, the error was in a Daylight Saving Time setup which was outdated as described in one of my previous posts, and the local admin manually correcting the time into a time which was actually one hour behind our domain’s time.

You can use the following Microsoft Knowledge Base article to read up on making sure your domains are up to date with new Timezone settings: http://support.microsoft.com/kb/914387/en-us

To set up your DST changes manually, Microsoft published an extensive Knowledge Base article to create the necessary modifications and replicate it throughout your organisation.

Do it quicker.

You can, using the Command Prompt or Run in the Start Menu, type in the corresponding Microsoft Management Console Snap-in Control file to open the correct domain.

For instance, to open up the Active Directory Users and Computers console for Contoso’s subsidiary in Paris (domain “paris.contoso.com”) you could use the following:

dsa.msc /domain=paris

This will open the Active Directory Users and Computers console with the paris domain opened.

Some of the other snap-ins you can open directly:

Awaiting my test environment for more technical articles, I’ll review my toolbox over the next few weeks, starting with the Windows Server 2003 Administration Tools Pack, or more commonly known as “adminpak.msi”.

Windows Server 2003 Administration Tools Pack

If you want to start being a system administrator, the Administration Tools Pack is the first thing you will be touching after setting up a Windows Server 2000 or 2003 and setting up your Active Directory.  In all Windows Server operating systems, the Administration Tools Pack is included in the installation, and all tools are available in the folder “Administrative Tools” under your Programs Start Menu folder.

The Pack includes the obvious Active Directory Users and Computers Management Console, to administer all common AD elements (users, groups and computers), but also lesser used utilities such as Domains and Trusts, or the foundations of any Active Directory setup: DNS and optional DHCP.

The Pack is not only available for Windows Server operating systems, but also for Windows XP, if you get the x86/x64 installation media from Microsoft.  Windows Vista is not officially supported, but since SP1 of the pack, installation on Vista is possible and works without a glitch.

In the end, the adminpak.msi (or its following versions with more elaborate filenames) is the first set of tools I require when starting a system administration position.  Where NT4 lacked good tools and you had to resort to Hyena or DameWare NT Utilities, Windows Server 2000 and 2003 actually had decent tools shipped with them.

There are sure other, easier and more elaborate tools which I’ll visit over the coming weeks.  But the Windows Server 2003 Administration Tools Pack is the basis for any good Windows Server environment.

Any ADSI or WMI query to a list of your group memberships will turn out to 1000 members in Windows 2000 mode, or 1500 in Windows 2003 native mode. Only by using ADO range limits, you can go by this soft limit.

This shouldn’t pose a problem when you are just adding members to an already big group. However, it does.

$userOU = [ADSI] "LDAP://cn=myUser,ou=Users,dc=contoso,dc=com"
$groupOU = [ADSI] "LDAP://cn=myGroup,ou=Users,dc=contoso,dc=com"
$groupOU.Member = $groupOU.Member + $userOU.distinguishedName
$groupOU.SetInfo()

Adding the myUser user to the myGroup group will work fine if the group member count is below 1500. Once above, your group will suddenly loose an amount of members until you are left with a group of just 1500 members, and then added by the new member.

What actually happens is self-explanatory when reading the code: the group members is the group member list plus the new member. When the group member list only returns 1500 members, and then you add one member, you are left with 1501 members, and not your original amount of members + 1.

A workaround is this:

$ADS_PROPERTY_APPEND = 3
$userOU = [ADSI] "LDAP://cn=myUser,ou=Users,dc=contoso,dc=com"
$groupOU = [ADSI] "LDAP://cn=myGroup,ou=Users,dc=contoso,dc=com"
$groupOU.putEx($ADS_PROPERTY_APPEND, "member", @($userOU.distinguishedname))
$groupOU.SetInfo()

In this workaround, we are going to use putEx to append a member to a group, instead of loading the full member list (with a limit of 1500) and then adding a new member.

Source.

In this post, I’ll explain how to run your own Subversion version control server to control your script development.  This is an update to this post for Subversion 1.4.5

Subversion

First of all, get the latest Windows compiled version of Subversion on their website.  This post covers the current 1.4.5 version, but should work for all 1.4.x versions. Install the package with the basic Win32 binaries.

After installation, open a command line window and type in the following:

svnadmin create "c:\Documents and Settings\Subversion Repository"

Navigate to the directory you just created.  Uncomment the following lines in the conf\svnserve.conf file:

[general]
anon-access = read
auth-access = write
password-db = passwd

Uncomment the following lines in the conf\passwd file:

[users]
harry = harryssecret
sally = sallyssecret

Make the svnserve service by using the following command one one single line:

sc <computername>
  create svnserve
  binpath= "c:\Program Files\Subversion\bin\svnserve.exe --service --root
  \"C:\Documents and Settings\Subversion Repository\""
  displayname= "Subversion Repository"
  depend= Tcpip

Notice that all <options> of the SC command have a <space> after the = sign.  Microsoft has a nice summary up on all SC options.

Notice also how the Repository path has been “escaped” by using \”.  You need to do this when your repository path contains spaces.

Type the following to get the service started:

net start svnserve

Next, make your first project:

svn mkdir svn://localhost/myproject

Subversion will create some default folders, and will open notepad with svn-commit.tmp where you can put in a comment.  Save the file, close it and the following will appear in your command line window:

Authentication realm: <svn://localhost:3690> dc1f5697-44ac-5745-849e-e86ad8f60265
Password for 'wooter': **********
Authentication realm: <svn://localhost:3690> dc1f5697-44ac-5745-849e-e86ad8f60265
Username: sally
Password for 'sally': ************

Committed revision 1.

As you can see, you first get asked for the password of your Windows user, and next one of the users defined in conf\passwd.

TortoiseSVN

Next, run the TortoiseSVN installer. Install the package with default settings.

Select a folder where you want to start your first version controlled project:

[photopress:subversion_tortoise_checkout.gif,full,centered]

Type in your repository URL and click OK:

[photopress:subversion_tortoise_checkout_2.gif,full,centered]

Create a new file in that directory, and add the file to your Subversion server

[photopress:subversion_tortoise_add_file.gif,full,centered]

Although you “added” the file, the file has not been checked into Subversion yet.  To commit all changes, right-click on the file or folder and select “SVN Commit”:

[photopress:subversion_tortoise_commit.gif,full,centered]

Now you can maintain your scripts in version control.

[photopress:dhcp_bindings_vmware.png,full,centered]

After hours of useless fiddling, with limited internet access, I found this possible solution, while my colleague figured the same thing through another means: deleting the virtual network adapter from the server, rebooting the server and letting the OS detect a ‘new’ virtual network adapter. The Bindings page checkbox was active again, and DHCP services were restored.

A day later, the client came up with the solution: switch on IIS 5.0 isolation mode in Windows Server 2003′s IIS 6.0:

[photopress:iis_50_isolationmode.gif,full,centered]