Migrating from a Novell NetWare environment to the Windows Server System

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

In my last job, I managed the migration of a major fashion design, marketing and retail company’s European business from Novell NetWare and GroupWise to a Microsoft platform. With a limited budget (none) for migration tools, only free utilities could be used and it worked, but was restrictive. This post discussed some of the alternatives that are available, based on a presentation from Microsoft’s Steve Plank at the IT Forum highlights event back in January.

NetWare has always been good at file and print, directory services, and management but traditionally it has lacked an application platform (although that is changing with Novell’s adoption of SuSE Linux) so many organisations have implemented Microsoft applications such as Exchange Server and SQL Server. Depending on the application, this may lead to a requirement for Active Directory (AD), and once the Windows servers for AD are in place, then it seems logical to provide file and print, or web services from the same infrastructure (IT Week recently reported that even Novell concedes that it has been losing between 12 and 15% of NetWare users every year for the last 4-5 years). This leads to a number of challenges around migration and interoperability. For many organisations, there is simply too big an investment in the existing environment to dump it all and move to a new platform, and so interoperability is a must; however by moving away from a mixed environment, support (and licensing) costs can be reduced, and the existing NetWare Directory Services (NDS)/eDirectory experience can even be used in planning the AD design.

There are a number of tools available to assist organisations with a migration to the Windows server system, the first of which is Microsoft Services for NetWare (SFN). Formerly chargeable, but now available as a free download, SFN provides:

  • File migration utility, which migrates files, preserving access controls (with some limitations as NetWare file attributes do not map directly onto the NTFS file system).
  • File and Print Services for NetWare, making a Windows server appear as a NetWare box (although only supporting the IPX transport and NetWare 3.x bindery mode – from v5.03 of SFN onwards, file and print services for NetWare, have been removed and are now available as a separate download).
  • Microsoft directory synchronisation services for NetWare (MSDSS), which provides 1- or 2-way synchronisation between NDS versions 4.x-6.x and AD; however there are some schema extensions required (which may or may not be desirable) and the Novell NetWare 32-bit client (v4.9 SP2) must also be installed (on a domain controller).

Third-party tools are also available (e.g. from Quest Software, who bought the previous Fastlane product set) and Microsoft is said to be producing solution accelerators to assist organisations in the transition.

It is important to bear in mind that data can co-exist in the two environments and that a migration is really a file copy. Therefore it is important to decommission old copies of data, to prevent two copies from being altered from users on different systems.

On the interoperability front, besides the gateway services for NetWare (GSNW) Windows server component (and client services for NetWare in Windows client operating systems), there is Microsoft Identity Integration Server (MIIS), which provides directory synchronisation, password management and user provisioning, or SFN can be used as a short term fix.

Implementing MSDSS for one way synchronisation from AD to NDS is good if AD is the focal point for management (e.g. as a short term, strategy until a move to AD can be completed), but is probably not sustainable in the long term. Two-way synchronisation allows both directories to be managed. There are some “gotchas” though:

  • Synchronisation is not real time – it works on a schedule, with an agent on the Windows side performing a push/pull operation.
  • More significantly, whilst AD does allow MSDSS to store passwords using reversible encryption, using a key which is only known by MSDSS, passwords cannot be passed from AD back to NDS as there is no reversible encryption option.

The file migration utility is actually a cut-down version of the Fastlane product, supporting NetWare versions 4.x, 5.x and 6.x as well as eDirectory 8.7.3. It preserves user permissions and provides some limited logging capabilities (although for reporting, the full product is required). Some considerations when using the tool include:

  • Data volumes (i.e. can all the data be physically migrated in the time available) – consequently, it may be appropriate to perform a trial run, then to actually migrated users and data in small volumes (scheduled for quiet times). One advantages of the migration may be the opportunity to consolidate server smaller servers into one.
  • Drive letters in document links – many Office applications, convert drive letters to UNC paths when saving documents. If the server location changes, then the link will be broken, although tools are available to assist in modifying this.
  • Encryption – encrypted files will need to be de-encrypted before they can be migrated.

There may also be migration considerations such as directory restructuring, removing the NetWare client from workstations and changes to login scripts, so whilst the free tools will be of use to many organisations, those enterprises with more than about 2000 users may wish to make use of third party tools. Quest Software’s NDS Migrator handles both object and data migration (together or as separate operations), with a central console for management which makes use of a mapping database to store metadata (either SQL Server or MSDE – although MSDE is limited to 2Gb in size).

NDS MigratorNDS Migrator is able to deal with a number of complex scenarios, as well as supporting the saving of configuration options (for a repeatable migration). Security principles are examined first, before attempting file migration, based on a file scan (during which information is written to the mapping database) and then finally a migration which uses the information from the database.

In NDS, a container is a security principle; whereas in AD, it is well known that security permissions cannot be applied to an OU. Instead, NDS Migrator creates global groups in AD called container permission equivalent groups (CPEGs), which correspond to an NDS container and are always named with a $ prefix.

NDS allows common names to be duplicated in different parts of the whereas AD common names must be unique. NDS Migrator handles this with pre-migration mapping and planning (identifying intra-NDS naming conflicts and remapping accordingly), as well as allowing for flexible migration (e.g. moving files to a new location), with a pre-migration file scan, Macintosh file support and a multi-threaded copy engine (the version in the SFN file migration utility is single-threaded).

Attribute mapping is supported, such that if NDS has been extended with additional attributes, these can be created in AD. It also handles the differences between NetWare and Windows file system permissions and file ownership (as NDS allows files to exist without an owner, but Windows does not).

It may be of interest that not all of Quest’s tools are available for purchase – some are only available to Quest’s professional services organisation, including NDS reporter (used to assess the NDS environment), workgroup migration tools, and a tool to remove the Novell NetWare client from Windows 2000 and XP clients.

In summary, there are many tools available to assist with the migration from NetWare to Windows and as with any migration, the key to success is in the planning. With careful preparation and by through becoming familiar with the tools that are available, administrators may be confident in performing a successful migration.

Links

Novell NetWare to Windows Server 2003 migration planning guide (Microsoft).
Quest NDS Migrator.

(Since I wrote the original notes for this post, the Microsoft TechNet Industry Insiders blog has carried another article on NDS Migrations, contributed by Darren Catteral from Quest Software).

Overview of Active Directory Application Mode

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I recently blogged about Microsoft Identity Integration Server (MIIS), which is Microsoft’s platform for connecting directory enabled applications and facilitating identity management. For organisations that require flexible support for directory enabled applications and for which organisational constraints or schema issues prevent the use of Active Directory (AD), Microsoft has developed Active Directory application mode (ADAM).

ADAM is a lightweight directory access protocol (LDAP) directory, providing many of the features of AD, but which can be used to support directory enabled applications that are not considered safe for use with AD. Although AD was designed to be extendable, possible concerns over safety could include:

  • Unacceptable schema changes.
  • Security risks.
  • Directory management requirements.
  • Development requirements.

ADAM runs as a user service (rather than as a system service) and multiple instances can be run concurrently on a single computer, with an independent configuration for each instance. Unlike AD, ADAM doesn’t have any dependencies on the domain name system (DNS) or file replication service (FRS). Instances that share the same configuration and schema can be added to a configuration set and will replicate changes to one another; however ADAM cannot replicate with AD – instead, there is a beta tool called the Active Directory to ADAM Synchronizer that provides one way synchronisation from AD to ADAM.

On the client side, ADAM supports any client that is written to the LDAP v3 technical specification as well as Active Directory service interfaces (ADSI) for clients from Windows 2000 onwards.

ADAM overviewTo illustrate where ADAM might be useful, here are three example scenarios:

  1. The first scenario is an intranet portal application for users that have been authenticated by AD. Because ADAM is integrated with the Windows security model, any application that is deployed using ADAM can authenticate access against AD across the enterprise. Global data is stored in AD, whilst application-specific data is stored in ADAM. As the application uses AD for authentication it doesn’t need to maintain its own database of user IDs and passwords (although this is supported if required) and because ADAM is used for the application’s personalisation data, there is no need to extend the AD schema. Different departments using the application may have different schema requirements and apply different business logic to directory data. The answer to this is ADAM’s support for multiple instances, each with their own schema, without needing to modify the enterprise schema or to manage yet another set of user accounts and passwords. These isolated ADAM instances may be deployed and managed locally or centrally.
    ADAM deployment scenario 1
  2. The second scenario is a web portal application that handles extranet access management. In this case the portal directory is used for authentication purposes only. ADAM can be used to store application information, while authenticating user objects using LDAP simple binds, allowing ADAM to work in heterogeneous environments and in situations where AD is not present (or is deliberately segregated).
    ADAM deployment scenario 2
  3. The final scenario considers an organisation in the process of migrating to AD but which still has applications that rely on an X.500 naming convention or directory. ADAM can serve as an interim solution to support the legacy applications through the migration process which using AD for user authentication and a shared security infrastructure. Optionally, MIIS can be used to transform identity information between AD, ADAM and any other identity stores in use. By using a single directory technology for both the network operating system and application directory needs, overall infrastructure costs are reduced as additional investments are not required for training, administration, or management of the application directory. The LDAP, ADSI, and directory services markup language (DSML) application programming interfaces are also equivalent between the two directory services, so that applications may be built on ADAM and then migrated to AD as needed, with minimal change.
    ADAM deployment scenario 3

By using ADAM to isolate application-specific information from AD and for simple authentication for extranet applications, organisations are able to develop, deploy and manage directory-enabled solutions without the need to create separate user databases or change the schema of AD to support each application. Because the ADAM directory can easily be installed, reinstall, or removed, it may be considered for deployment with an application.

Similar to the partition structure in AD, ADAM consists of a number of naming contexts (NCs), which are:

  • Configuration NC – CN=Configuration,CN={GUID}
  • Schema NC – CN=Schema,CN=Configuration,CN={GUID}
  • One or more application directory partitions (ADPs), e.g. cn=partition1,dc=markwilson,dc=co,dc=uk.

The configuration and schema NCs are provided by default and are automatically configured, with the application directory partitions specified by the administrator. Note that they are defined by an instance GUID, and not using DNS names. Because it is an LDAP directory, ADAM can also support x.500 names for integration with legacy applications (LDAP was designed as a lightweight version of the X.500 directory access protocol).

ADAM can be installed on computers running any version of Windows XP or Windows Server 2003 (32- or 64-bit) and does not require a forest, domain, or domain controller so can be installed on computers that are configured as domain controllers, domain members or workgroup members.

During installation the only options required are:

  • Acceptance of the license agreement.
  • Whether or not to install the ADAM administration tools.
  • Whether to install a unique instance, or a replica of an existing instance.
  • Instance name (a service will be created named ADAM_instancename).
  • LDAP and SSL port numbers (389 and 636 by default, but these should be changed to high numbered ports if AD is or will be installed on the same computer).
  • Whether or not to install an ADP (and if so, the ADP name) – some applications will create their own ADP on installation.
  • Data and data recovery file locations (by default, %Program Files%\Microsoft ADAM\instancename\data.
  • Service account information (network or a specified account).
  • ADAM administrator details.
  • Any lightweight directory interchange format (LDIF) files to extend the application partition schema – these can also be imported at a later time, using LDIF directory exchange utility (ldifde.exe).

Once installed, ADAM has a limited toolset, with ADAM ADSI Edit, ADAM Help and the ADAM Tools Command Prompt. Many of the command prompt tools have the same names as their AD counterparts, so it is important to use the correct command prompt.

ADAM security is based on the AD model, with the majority of default permissions set on the NC head for a number of default groups, held in the roles container for each partition. For an application directory partition, the default groups are Administrators, Readers and Users. There is no user interface for setting security, instead the ADAM version of the dsacls.exe support tool is used although the ldp.exe support tool is useful for viewing security descriptors. An LDAP simple bind is used for ADAM security principles, whilst for Windows security principles, a simple authentication and security layer (SASL) bind is used (either Kerberos or NTLM) and there is also provision for binding to ADAM and redirecting to AD via an ADAM proxy object. Anonymous access is also available, controlled using the dSHeuristics flag (in the configuration directory partition – CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID} – on which various bits are set to indicate various directory operations, detailed in the product documentation).

Although ADAM cannot replicate objects to and from AD (for that, either MIIS or the Identity Integration Feature Pack for Active Directory is required), the AD to ADAM Synchronizer allows application administrators and developers to use an XML configuration file and a scriptable command line interface to specify a filtered and scoped subset of data to be pulled from AD to ADAM.

No data is written back to AD and the objects and values in ADAM are not transformed in any way. Object or attribute based evaluation rules cannot be implemented and values from the source (AD) are authoritative. While the application may extend the data stored in ADAM, any shared data will be overwritten on subsequent runs, with data values from AD.

Using the ADAM synchronizer involves:

  • Extending the ADAM schema to support the ADAM synchronizer along with the attributes and objects that are to be imported.
  • Setting the appropriate fields in the ADAM synchronizer’s conf_public.xml file and loading the file.
  • Running the synchronisation.

ADAM looks to be a useful addition to the Microsoft directory services toolset. I only wish that some of the Microsoft applications used it so I could avoid extending the AD schema for them (e.g. Exchange, ISA Server and SharePoint Portal Server).

Credits

Although I have provided additional information from my own research, the inspiration for this blog post was a seminar hosted by Microsoft, during which John Craddock and Sally Storey from Kimberry Associates presented on stretching directory boundaries: cross platform identity management, authentication and security. The ADAM deployment scenarios above were taken from Microsoft’s ADAM overview presentation.

New features of Windows Server 2003 Active Directory

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A couple of weeks back, I was at a Microsoft TechNet UK event, where the topic was New features of Windows Server 2003 Active Directory, presented by John Howard, IT Pro Evangelist, Microsoft UK.

I’ve been working with Active Directory (AD) since the early days of Windows 2000 (windows NT 5.0 as it was then), and to be perfectly honest wondered how much there could be that’s new with the latest version. Whilst the session was possibly a little lightweight, I was surprised to learn just how many new features there are, as my previous view of Windows Server 2003 was that much of the improved functionality comes in the form of new services.

The new AD features fall into in four main areas:

  • Simplified management.
  • Connecting forests.
  • Connecting small offices.
  • Managing group policies.

The rest of this post will discuss each of these in turn.

Simplified management
Simplified management is about improving the user experience for administrators. For example, within the AD User and Computers and AD Sites and Services Active Directory management tools, users can now drag and drop users into new containers, OUs or groups, e.g. when adding user(s) or group(s) to a group, or moving a server to a new site.

Tip: Within AD users and computers it helps if the option to view users, groups and computers as containers is selected.

Improvements have also been made in locating objects, with new functionality such as saved queries in AD users and computers, accessed like a folder, e.g. queries based on a user or group name or description, or the number of days since the last logon). The queries are LDAP-based and can have their own root (i.e. do not have to be relative to the whole domain). It should also be noted that saved queries are local to the computer and can be exported – e.g. űbergeek queries can be created and exported to a help desk machine.

Tip: To see exactly where an object exists in the directory, turn on advanced features and look in the object page of the item properties.

There are also a whole head of new tools, which can be called from the command line or from within custom scripts, allowing for repetitive tasks to be automated and complex commands to be simplified. Back in September 2004, I posted further information on new commands in recent Windows releases and Microsoft knowledge base article 322684 discusses using the directory service command-line tools to manage Active Directory objects in Windows Server 2003.

Connecting forests
It is now possible to connect forests using trusts (e.g. following a merger or acquisition, of under some business partnership scenarios), simplifying access to resources in both forests, and facilitating single sign-on.

Forest trusts can be one- or two-way and create a transitive trust between the domains in each forest, but not between forests. With a forest trust, UPN suffixes are used to publish namespaces, which in turn are used to establish where a logon originates from. Each forest is trusted to be authoritative for the namespace(s) which it publishes.

In order to support forest trusts, both forests must be running at Windows Server 2003 forest functional level.

Connecting small offices
Small or branch offices are often characterised by low speed wide area network links and may not have a local global catalog server, leading to slow logons. Windows Server 2003 includes a new option in the Active Directory Installation Wizard (dcpromo) to create a domain controller from a replica. It works by backing up the system state from an existing domain controller to removable media, then restoring that data on a remote server and running dcpromo /adv. In this way, the initial synchronisation time is reduced, as all the new domain controller needs to synchronise is the changes since the backup was taken. There is one gotcha through – the backup cannot be older than the tombstone lifetime (60 days by default).

Another useful new feature when connecting small offices is universal group membership caching. Because universal groups may span multiple domains, a global catalog server is required to query the membership (non-global catalog-enabled domain controllers only hold full details for objects in their own domain).

By caching the membership lists for universal groups, global catalog lookups only need to occur once for each universal group. The membership list is held indefinitely, but is refreshed every 8 hours. Universal group membership caching is enabled at the site level, within the NTDS Site Settings.

One alternative to universal group membership caching is to make each branch office domain controller a global catalog server, but this has a cost in increased domain replication traffic.

Managing group policies
One of the major criticisms of Active Directory group policy objects (GPOs) is that they are is difficult to administer. Microsoft does provide tools, but until recently, they have been limited in their capabilities. Shortly after Windows Server 2003 was released, Microsoft made the Group Policy Management Console (GPMC) available for download. Since then, GPMC with service pack 1 has been released which includes a number of bug fixes, revised licensing (to allow GPMC to be run against Windows 2000 domain controllers), support for more languages and a revised XML engine.

The GPMC is a new administrative tool for centralised management of GPOs, together with a collection of scriptable objects and associated scripts, which use a combination of Windows Management Instrumentation (WMI), Active Directory Services Interfaces (ADSI) and the GPMC object model.

Surprisingly, although in almost every organisation which uses Active Directory, GPOs affect every user within the business, many organisations do not think about backing up and restoring GPOs. Whilst they can be restored with an authoritative AD restore, that is not a simple process, and the scripts provided with the GPMC allow policies to be backed up and restored, as well as exported and imported (e.g. between test and production domains/forests).

Tip: Beware (as I found out with one of my clients), that if naming standards allow the use of non-standard characters (e.g. & and ‘) the GPMC scripts may not work as intended. For further information, refer to the September 2004 post which discusses recommendations for Active Directory object naming.

The GPMC also allows modelling of group policies in a similar manner to the previous Resultant Set of Policy (RSoP) tool. This is particularly useful for its ability to highlight the winning GPO for a policy setting, as well as the ability to view (and save) reports in HTML, or XML format (e.g. for intranet publishing and reference by IT support staff). Note that some settings (e.g. WMI, loopback, IPSec, Wireless, and disk quotas) may be estimates. Also, if a client PC used for modelling is running Windows XP service pack 2 with the default Windows Firewall settings and the original version of GPMC is used (i.e. without service pack 1), it will fail as described in Microsoft knowledge base article 883611.

Other useful group policy management tools include Group Policy Monitor (gpmonitor), which is used to create and display reports when policy settings are refreshed and the Group Policy Verification Tool (gpotool), which allows administrators to check GPO stability and monitor policy replication including checking for consistency within and across domains. This tool also displays information about GPOs, including properties that cannot be accessed through the Group Policy Object Editor such as the functionality version number and extension globally unique identifiers (GUIDs). Other diagnostic tools (also available in Windows XP) include Group Policy Results (gpresult) and the Group Policy Refresh Utility (gpupdate).

When diagnosing issues with GPOs, it is also worth checking DNS, as at the event I attended, Microsoft commented that 50% of GPO-related support calls are actually DNS issues.

Another new feature of Windows Server 2003 group policy is software restriction policies, which can be used to confront the problem of regulating unknown or untrusted code. Software restriction policy rules create one or more exceptions to the default security level, defined by software restriction policies.

The following types of software restriction policy rules can be created:

  • Certificate rules, which recognise software that is digitally signed by an authenticode software publisher certificate.
  • Hash rules, which recognise specific software based on a hash of the software.
  • Path rules, which recognise software based on the location in which the software is stored.
  • Registry path rules, which recognise software based on the location of the software as it is stored in the registry.
  • Internet zone rules, which recognise software based on the zone of the Internet from which the software is downloaded.

Handy script for determining when a user last logged on

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I recently came across a handy script which examines a Windows NT/2000/XP/2003 computer or an Active Directory domain controller to read out the last log on time for each user. By piping the output to a text file, it could be useful for sorting and identifying redundant user accounts.

Active Directory system volume placement

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I came across a useful tip on the Microsoft website today, entitled “Why is placing the Sysvol directory on a separate partition a good practice?” As links like this have a habit of disappearing from the Microsoft website, I’ve reproduced the content below:

“The System Volume (Sysvol) shared directory is replicated to every domain controller in a domain by means of the File Replication Service (FRS). Here are a couple of good reasons for placing Sysvol on a separate partition:

  • Sysvol’s contents and its staging files might increase in size. Placing Sysvol on a separate partition contains the growth of the directory’s contents and prevents them from consuming space on the boot partition, thereby preventing problems with other components and performance degradation.
  • Placing Sysvol on its own NTFS partition minimizes disk I/O, thereby reducing the chances of receiving journal wrap errors. FRS uses the NTFS journal to monitor changes in the file system. The journal contains the update sequence number (USN) of the NTFS changes that are stored on each NTFS partition. If FRS can’t keep up with the pace of disk I/O or if FRS is turned off for a period of time, the USN that’s referenced in the FRS log might no longer exist in the NTFS volume journal. To help reduce the chance of the NTFS journal wrapping before FRS has replicated content, Windows 2000 Service Pack 3 increased the size of the NTFS journal from 32Mb 512Mb by default (with a maximum configurable limit of 10Gb).”

Priority order for the application of GPOs

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

The group policy management console (GPMC) integrates group policy functionality from a variety of Active Directory administrative tools into a single, unified console dedicated to group policy management tasks. One of the many useful features of GPMC is the ability to carry out group policy modelling, for example when diagnosing issues with GPO application.

Policies are applied in the following order:

  1. Local
  2. Site
  3. Domain
  4. Organizational unit (OU)
  5. Child OU
  6. [Child OU etc.]

When a container (site, domain or OU) has links to multiple GPOs, these can be assigned a link order to designate an order of precedence. Sounds straightforward enough, except that to me, the term “link order” suggests the order in which links to GPOs are applied – i.e. 1, then 2, then 3, etc. In that way, if GPO a (with link order 1) is overridden by a setting in GPO b (with link order 2), then GPO b (second to be applied) would be the winning GPO. Except that it doesn’t work that way!

Microsoft’s Group Policy Management Console Technical Reference provides a full description of how GPMC can be used, and provided me with a gem of information that seems to me totally illogical, but solved a problem I’ve been struggling with this afternoon:

“When a container has multiple GPO links, administrators can use GPMC to manipulate the link order for every container. GPMC assigns each link a link order number; the GPO link with link order of 1 has highest precedence on that container.”

The GPO with link order 1 has the highest priority – i.e it is applied last! I switched the policy link order and now the resultant set of policies is exactly the way I need it to be.

Using group policy objects to hide specified drives in My Computer

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Whilst locking down the Windows XP desktop using an Active Directory group policy object, I needed to prevent access to certain drive letters that didn’t fall within the default settings. Microsoft knowledge base article 231289 details the process for editing the system.adm file to provide more control over access to particular drives.

I chose to write my own .adm file with just the relevant settings (although it fails to load in the same policy as system.adm, due to duplicate definitions, so needs to be applied through a separate policy).

Script to disable password expiry for local Windows accounts

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of the shortcomings of the net user command in Windows is the inability to set the password never expires flag on an account (account expiry options can be set, but not password expiry and the full syntax is described in Microsoft knowledge base article 251394).

There are 13 flags on an NT SAM/Active Directory user account which may be manipulated using VBScript (for further details of the 13 flags, see Microsoft’s sample scripts or there is some useful information about the object model at the Motobit Software website).

This script can be used to set the password never expires flag on a specified account. I’ve tested it against the local SAM database on a Windows XP PC, but in theory it should work on all versions of Windows NT (2000, XP, 2003 Server, etc.) and also against Active Directory accounts if you run it on a domain controller.

Recommendations for Active Directory object naming

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Microsoft publishes best practice guidance under the general heading of Microsoft solutions for management. All of these best practices are based on the Microsoft Operations Framework (MOF), which includes guidelines on how to plan, deploy, and maintain IT operational processes in support of mission-critical service solutions.

Within this guidance is the Account Management for Windows Server 2003 Solution Accelerator, specifically the User and Location Management Guide, which contains conceptual information, best practices, and detailed procedures related to managing the creation, changing, or deletion of user accounts and physical locations. In the last chapter of this document are some Active Directory object naming conventions, which are actually quite restrictive – basically the only allowed characters are:

  • Uppercase letters A…Z
  • Lowercase letters a…z
  • Numbers 0…9
  • ä (= ae), Ä (= AE)
  • ö (= oe), Ö (= OE)
  • ü (= ue), Ãœ (= UE)
  • ß (= ss)
  • Underscore (_)
  • Minus sign (-)

Interestingly, no mention is made of other accented characters (e.g. ç or é).

I came across this whilst researching issues with Group Policy Management Console (GPMC) scripts producing errors when certain non-alphanumeric characters were parsed, but as general advice and guidance, adhering to these standards should be seriously considered, even though various AD management tools allow other characters to be used.

Issues when editing Windows XP SP2 group policy objects

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’m working with Microsoft on a client site and one of the potential issues we raised today was around the impact of the new group policy settings supporting Windows XP SP2. SP2 provides administrators with .ADM templates for 1378 group policy settings (although only 87 seem to relate specifically to SP2; 1 more to computers with SP2 or BITS 2.0; and a further 518 to Internet Explorer 6.0 in Windows XP SP2). Full details are available from Microsoft; however there are issues that need to be resolved with a hotfix when editing policies that use the new .ADM templates on non-Windows XP SP2 computers, as described in Microsoft knowledge base article 842933.

Microsoft have also published a white paper providing best practice for managing Windows XP SP2 features using group policy.