Wednesday, December 31, 2008

Convert change alter NVarchar and Text to Varchar


declare @schema table (tblName varchar(128), colName varchar(64), colLen int)
insert into @schema
select SO.Name, SC.name, convert(int, sc.length) as Length from sysobjects SO
join syscolumns SC on SC.id = so.id
where type_name(SC.xusertype) in ('text', 'nvarchar')
/*
and SC.Name NOT in
(select name from syscolumns where name like 'DF_%')
*/
and SO.xtype <> 'P' and SO.name like 'tbl%'
order by SO.name, SC.name
select * from @schema

declare @tName varchar(128), @cName varchar(128), @len int

declare @altString nvarchar(512)
declare Change Cursor for select * from @schema
open Change
fetch next from change into @tName, @cName, @len
while @@FETCH_STATUS = 0
begin
--
set @altString = 'alter table ' + @tName + ' Alter Column ' + @cName + ' varchar(' + cast(@len / 2 as Varchar(4)) + ')'
EXECUTE sp_executeSQL @altString
fetch next from change into @tName, @cName, @len
END
close change
deallocate change

利用 DenyHosts 軟體擋掉暴力破解 ssh 的使用者

[FreeBSD]利用 DenyHosts 軟體擋掉暴力破解 ssh 的使用者

Dec 26th, 2008 by appleboy 參觀者:5,389Views 機器人:1,188Views

不管是架設好 Linux 跟 FreeBSD 通常都會有國外的 hacker 來 try 機器的 SSH 帳號密碼,我想這是很正常的,網路上也提供很多方法來分析 Log 檔,FreeBSD:/var/log/auth.log,我可以分析檔案,然後再利用 firewall like ipfw or pf 的方式來達到,或者是利用寫到 /etc/hosts.deny 來達到 Block 的功能,網路上有很多工具可以用,例如 DenyHosts,sshguard 或者是 sshit,可以參考我之前寫的一篇利用 sshit 來達到阻擋 ssh 使用者,然而今天來介紹一下 DenyHosts 再 FreeBSD 底下如何設定,還蠻方便的。

首先利用 ports 安裝,DenyHosts 是利用 python 的程式語言寫出來的:
Port: denyhosts-2.6_2
Path: /usr/ports/security/denyhosts
Info: Script to thwart ssh attacks
Maint: janos.mohacsi@bsd.hu
B-deps: python25-2.5.2_3
R-deps: python25-2.5.2_3
WWW: http://denyhosts.sourceforge.net/

/* 利用 ports 安裝 */
cd /usr/ports/security/denyhosts; make install clean


安裝好之後接下來設定系統
#
# 在 /etc/rc.conf 加入 denyhosts_enable="YES"
#
denyhosts_enable="YES"
#
# 編輯 /etc/hosts.allow 加入
#
sshd : /etc/hosts.deniedssh : deny
sshd : ALL : allow
#
# 假如 /etc/hosts.deniedssh 不存在,那就新增一個
#
touch /etc/hosts.deniedssh

接下來就是設定 /usr/local/etc/denyhosts.conf
#
# 設定需要分析 Log 檔案位置
#
# FreeBSD or OpenBSD
SECURE_LOG = /var/log/auth.log
# Redhat or Fedora Core:
#SECURE_LOG = /var/log/secure
# SuSE:
#SECURE_LOG = /var/log/messages

#
# 我們要阻擋的 IP 寫入到的檔案
#
HOSTS_DENY = /etc/hosts.deniedssh
#
# 我們要清除 hosts.deniedssh 裡面的 entries
# 'm' = minutes
# 'h' = hours
# 'd' = days
# 'w' = weeks
# 'y' = years
# 格式:i[dhwmy] i 是數字
PURGE_DENY = 5d
#
# 我們要阻擋的服務:sshd
#
BLOCK_SERVICE = sshd
#
# 如果該帳號不存在 /etc/passwd 嘗試超過5次失敗,就阻擋該ip登入此服務
#
DENY_THRESHOLD_INVALID = 5
#
# 如果該帳號存在 /etc/passwd 嘗試超過10次失敗,就阻擋該ip登入此服務
#
DENY_THRESHOLD_VALID = 10
#
# 阻擋 root 帳號錯誤登入次數,不過這對 FreeBSD 沒影響
# 因為 FreeBSD 架設完成,是不能遠端利用 root 登入的
DENY_THRESHOLD_ROOT = 1
#
# 把 deny 的 host 或者是 ip 紀錄到 Work_dir 裡面
# 盡量把這資料夾改變到 root 帳號以外不能存取的地方
#
WORK_DIR = /usr/local/share/denyhosts/data
#
# 設定 deny host 寫入到該資料夾
#
DENY_THRESHOLD_RESTRICTED = 1
#
# 當 DenyHOts 啟動的時候寫入 pid,已確保服務正確啟動,防止同時啟動多個服務
#
LOCK_FILE = /var/run/denyhosts.pid
#
# 這裡可以設定 denyhost 寄發 email 給管理者
#
ADMIN_EMAIL = xxxx@gmail.com
#
# 如果設定了 ADMIN_EMAIL 下面就要設定 smtp 的 host
#
SMTP_HOST = localhost
SMTP_PORT = 25
# 發信的 header
SMTP_FROM = DenyHosts
# 發信標題
SMTP_SUBJECT = DenyHosts Report
#
# DenyHosts log 紀錄檔案
#
DAEMON_LOG = /var/log/denyhosts

這樣大致上完成了。

Fill Factor

Fill Factor

The fill-factor option is provided for fine-tuning index data storage and performance. When an index is created or rebuilt, the fill-factor value determines the percentage of space on each leaf-level page to be filled with data, reserving the remainder on each page as free space for future growth. For example, specifying a fill-factor value of 80 means that 20 percent of each leaf-level page will be left empty, providing space for index expansion as data is added to the underlying table. The empty space is reserved between the index rows rather than at the end of the index.

The fill-factor value is a percentage from 1 to 100, and the server-wide default is 0 which means that the leaf-level pages are filled to capacity.

ms177459.note(en-us,SQL.100).gifNote:
Fill-factor values 0 and 100 are the same in all respects.

You can use the CREATE INDEX or ALTER INDEX statements to set the fill-factor value for individual indexes. To modify the server-wide default value, use the sp_configure system stored procedure. To view the fill-factor value of one or more indexes, use sys.indexes.

ms177459.note(en-us,SQL.100).gifImportant:
The fill-factor setting applies only when the index is created, or rebuilt. The SQL Server Database Engine does not dynamically keep the specified percentage of empty space in the pages. Trying to maintain the extra space on the data pages would defeat the purpose of fill factor because the Database Engine would have to perform page splits to maintain the percentage of free space specified by the fill factor on each page as data is entered.

Page Splits

A correctly chosen fill-factor value can reduce potential page splits by providing enough space for index expansion as data is added to the underlying table.When a new row is added to a full index page, the Database Engine moves approximately half the rows to a new page to make room for the new row. This reorganization is known as a page split. A page split makes room for new records, but can take time to perform and is a resource intensive operation. Also, it can cause fragmentation that causes increased I/O operations. When frequent page splits occur, the index can be rebuilt by using a new or existing fill-factor value to redistribute the data. For more information, see Reorganizing and Rebuilding Indexes.

Although a low, nonzero fill-factor value may reduce the requirement to split pages as the index grows, the index will require more storage space and can decrease read performance. Even for an application oriented for many insert and update operations, the number of database reads typically outnumber database writes by a factor of 5 to 10. Therefore, specifying a fill factor other than the default can decrease database read performance by an amount inversely proportional to the fill-factor setting. For example, a fill-factor value of 50 can cause database read performance to decrease by two times. Read performance is decreased because the index contains more pages, therefore increasing the disk IO operations required to retrieve the data.

Adding Data to the End of the Table

A nonzero fill factor other than 0 or 100 can be good for performance if the new data is evenly distributed throughout the table. However, if all the data is added to the end of the table, the empty space in the index pages will not be filled. For example, if the index key column is an IDENTITY column, the key for new rows is always increasing and the index rows are logically added to the end of the index. If existing rows will be updated with data that lengthens the size of the rows, use a fill factor of less than 100. The extra bytes on each page will help to minimize page splits caused by extra length in the rows.

How To Find Servers That Hold Flexible Single Master Operations Roles

This article describe how to find the servers that hold the Flexible Single Master Operation (FSMO) roles in a forest. Active Directory defines five FSMO roles:

* Schema master
* Domain naming master
* RID master
* PDC master
* Infrastructure master

The schema master and the domain naming master are per-forest roles. Therefore, there is only one schema master and one domain naming master per forest.

The RID master, the PDC master, and the infrastructure master are per-domain roles. Each domain has its own RID master, PDC master, and infrastructure master. Therefore, if a forest has three domains, there are three RID masters, three PDC masters, and three infrastructures masters.

Back to the top
How to Determine the RID, PDC, and Infrastructure FSMO Holders of a Selected Domain

1. Click Start, click Run, type dsa.msc, and then click OK.
2. Right-click the selected Domain Object in the top left pane, and then click Operations Masters.
3. Click the PDC tab to view the server holding the PDC master role.
4. Click the Infrastructure tab to view the server holding the Infrastructure master role.
5. Click the RID Pool tab to view the server holding the RID master role.


Back to the top
How to Determine the Schema FSMO Holder in a Forest

1. Click Start, click Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Schema, click Close, and then click OK.
3. Right-click Active Directory Schema in the top left pane, and then click Operations Masters to view the server holding the schema master role.

NOTE: For the Active Directory Schema snap-in to be available, you may have to register the Schmmgmt.dll file. To do this, click Start, click Run, type regsvr32 schmmgmt.dll in the Open box, and then click OK. A message is displayed that states the registration was successful.

Back to the top
How to Determine the Domain Naming FSMO Holder in a Forest

1. Click Start, click Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Domains and Trusts, click Close, and then click OK.
3. In the left pane, click Active Directory Domains and Trusts.
4. Right-click Active Directory Domains and Trust, and then click Operations Master to view the server holding the domain naming master role in the Forest.


Back to the top
Using the Windows 2000 Server Resource Kit
The Windows 2000 Resource Kit contains a .cmd file called Dumpfsmos.cmd that you can use to quickly list FSMO role owners for your current domain and forest. The .cmd file uses Ntdsutil.exe to enumerate the role owners. The Dumpfsmos.cmd file contains:

@echo off
REM
REM Script to dump FSMO role owners on the server designated by %1
REM

if ""=="%1" goto usage

Ntdsutil roles Connections "Connect to server %1" Quit "select Operation Target" "List roles for connected server" Quit Quit Quit

goto done

:usage

@echo Please provide the name of a domain controller (i.e. dumpfsmos MYDC)
@echo.

:done




Back to the top
Using the NTDSUTIL Tool
NTDSUTIL is a tool included with Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Datacenter Server. This tool is can be used to verify change certain aspects of the Active Directory. The following is the steps needed to to view the Flexiible Single Master Operation (FSMO) roles on a given Domain Controller.

Ntdsutil.exe is the only tool that shows you all the FSMO role owners. You can view the PDC emulator, RID master, and infrastructure master role owners in Active Directory Users and Computers. You can view the schema master role owner in the Active Directory Schema snap-in. You can view the domain naming master role owner in Active Directory Domains and Trusts.

1. Click Start, click Run, type cmd in the Open box, and then press ENTER.
2. Type ntdsutil, and then press ENTER.
3. Type domain management, and then press ENTER.
4. Type connections, and then press ENTER.
5. Type connect to server ServerName, where ServerName is the Name of the Domain Controller you would like to view, and then press ENTER.
6. Type quit, and then press ENTER.
7. Type select operation target, and then press ENTER.
8. Type list roles for connected server, and then press ENTER.

A list is displayed similar to what is listed below. Results may very depending on the roles the particular Domain Controller may hold. If you receive an error message, check the spelling of the commands as the syntax of the commands must be exact. If you need the syntax of a command, type ? at each prompt:

Server "dc1" knows about 5 roles
Schema - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=com
Domain - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=com
PDC - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=com
RID - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=com
Infrastructure - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=com
Back to the top
USING DCDIAG
On a Windows 2000 Domain Controller, run the following command:

DCdiag /test:Knowsofroleholders /v


You must use the /v switch. This lists the owners of all FSMO roles in the enterprise.




Back to the top
REFERENCES
For additional information, click the article numbers below to view the articles...
For additional information, click the article numbers below to view the articles in the Microsoft Knowledge Base:
235617 (http://support.microsoft.com/kb/235617/EN-US/ ) How to Find the FSMO Role Owners Using ADSI and WSH
197132 (http://support.microsoft.com/kb/197132/EN-US/ ) Windows 2000 Active Directory FSMO Roles
223346 (http://support.microsoft.com/kb/223346/EN-US/ ) FSMO Placement and Optimization on Windows 2000 Domains

Tuesday, December 30, 2008

Custom Windows install CD with extra drivers RAID SCSI Controller

I will post what I changed to get my Adaptec 2930U2 SCSI controller recognized during the install without having to use a floppy. I would imagine that the changes required for your device should be pretty similar.

First, what you will want to use the makecab utility found in the \winnt\system32 directory to make cab files of your .sys (driver) and .inf (setup) files. Mine were 2930U2.sys and 2930U2.inf which in turn became 2930U2.sy_ and 2930U2.in_ respectively. You will need to copy these files to the i386 directory that will be burned on your CD.

There are only 2 files that you will have to edit:

DOSNET.INF and TXTSETUP.SIF

Under DOSNET.INF I made the following changes:

[FloppyFiles.2]
I added:
d1,2930U2.sys

[Strings]
I added:
2930U2 = "Adaptec 2930U2 Ultra2 PCI SCSI Controller"

[Files]
(Be careful, there are two sections labeled this, you want the 2nd, it also has a very long list after it.) I added:
d1,2930U2.sys


Under TXTSETUP.SIF I made the following changes:

[SourceDisksFiles]
I added:
2930U2.inf = 1,,,,,,,20,0,0
2930U2.sys = 1,,,,,,3_,4,1

[HardwareIdsDatabase]
I added:
PCI\VEN_9005&DEV_0011&SUBSYS_01819005 = "2930U2"


[SCSI.Load]
I added:
2930U2 = 2930U2.sys,4

[SCSI]
I added:
2930U2 = "Adaptec 2930U2 Ultra2 PCI SCSI Controller"

The stuff in quotes is just a text string so nothing special there that I can tell. The only item I see that would be a problem is the PCI\Ven... etc. part. I got the value by opening the registry on a box that already had the adapter installed and went to the HKLM\System\ControlSet001\Enum\PCI key and searched through the values until I found the key that had the adapter that I was looking for.

Alternately, there was a similar setting in the .inf file that is provided with your hardware, I'm not sure if that would work, but I'd bet that it probably would. Mine showed PCI\VEN_9005&DEV_0011 vs. what I entered above.

I hope that helps, or at least gives you a headstart on it. If you want some more help, post your .inf and .sys files or link to the download from the manufacturer and I would be glad to take a look with you.

Monday, December 29, 2008

Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller

Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
View products that this article applies to.
This article was previously published under Q255504
On This Page

* SUMMARY
* MORE INFORMATION
o Transfer FSMO roles
o Seize FSMO roles

Expand all | Collapse all
SUMMARY
This article describes how to use the Ntdsutil.exe utility to transfer or to se...
This article describes how to use the Ntdsutil.exe utility to transfer or to seize Flexible Single Master Operations (FSMO) roles.
Back to the top
MORE INFORMATION
Certain domain and enterprise-wide operations that are not good for multi-master...
Certain domain and enterprise-wide operations that are not good for multi-master updates are performed by a single domain controller in an Active Directory domain or forest. The domain controllers that are assigned to perform these unique operations are called operations masters or FSMO role holders.

The following list describes the 5 unique FSMO roles in an Active Directory forest and the dependent operations that they perform:

* Schema master - The Schema master role is forest-wide and there is one for each forest. This role is required to extend the schema of an Active Directory forest or to run the adprep /domainprep command.
* Domain naming master - The Domain naming master role is forest-wide and there is one for each forest. This role is required to add or remove domains or application partitions to or from a forest.
* RID master - The RID master role is domain-wide and there is one for each domain. This role is required to allocate the RID pool so that new or existing domain controllers can create user accounts, computer accounts or security groups.
* PDC emulator - The PDC emulator role is domain-wide and there is one for each domain. This role is required for the domain controller that sends database updates to Windows NT backup domain controllers. The domain controller that owns this role is also targeted by certain administration tools and updates to user account and computer account passwords.
* Infrastructure master - The Infrastructure master role is domain-wide and there is one for each domain. This role is required for domain controllers to run the adprep /forestprep command successfully and to update SID attributes and distinguished name attributes for objects that are referenced across domains.

The Active Directory Installation Wizard (Dcpromo.exe) assigns all 5 FSMO roles to the first domain controller in the forest root domain. The first domain controller in each new child or tree domain is assigned the three domain-wide roles. Domain controllers continue to own FSMO roles until they are reassigned by using one of the following methods:

* An administrator reassigns the role by using a GUI administrative tool.
* An administrator reassigns the role by using the ntdsutil /roles command.
* An administrator gracefully demotes a role-holding domain controller by using the Active Directory Installation Wizard. This wizard reassigns any locally-held roles to an existing domain controller in the forest. Demotions that are performed by using the dcpromo /forceremoval command leave FSMO roles in an invalid state until they are reassigned by an administrator.

We recommend that you transfer FSMO roles in the following scenarios:

* The current role holder is operational and can be accessed on the network by the new FSMO owner.
* You are gracefully demoting a domain controller that currently owns FSMO roles that you want to assign to a specific domain controller in your Active Directory forest.
* The domain controller that currently owns FSMO roles is being taken offline for scheduled maintenance and you need specific FSMO roles to be assigned to a “live” domain controller. This may be required to perform operations that connect to the FSMO owner. This would be especially true for the PDC Emulator role but less true for the RID master role, the Domain naming master role and the Schema master roles.

We recommend that you seize FSMO roles in the following scenarios:

* The current role holder is experiencing an operational error that prevents an FSMO-dependent operation from completing successfully and that role cannot be transferred.
* A domain controller that owns an FSMO role is force-demoted by using the dcpromo /forceremoval command.
* The operating system on the computer that originally owned a specific role no longer exists or has been reinstalled.

As replication occurs, non-FSMO domain controllers in the domain or forest gain full knowledge of changes that are made by FSMO-holding domain controllers. If you must transfer a role, the best candidate domain controller is one that is in the appropriate domain that last inbound-replicated, or recently inbound-replicated a writable copy of the “FSMO partition” from the existing role holder. For example, the Schema master role-holder has a distinguished name path of CN=schema,CN=configuration,dc=, and this mean that roles reside in and are replicated as part of the CN=schema partition. If the domain controller that holds the Schema master role experiences a hardware or software failure, a good candidate role-holder would be a domain controller in the root domain and in the same Active Directory site as the current owner. Domain controllers in the same Active Directory site perform inbound replication every 5 minutes or 15 seconds.

The partition for each FSMO role is in the following list:

Collapse this tableExpand this table
FSMO role Partition
Schema CN=Schema,CN=configuration,DC=
Domain Naming Master CN=configuration,DC=
PDC DC=
RID DC=
Infrastructure DC=


A domain controller whose FSMO roles have been seized should not be permitted to communicate with existing domain controllers in the forest. In this scenario, you should either format the hard disk and reinstall the operating system on such domain controllers or forcibly demote such domain controllers on a private network and then remove their metadata on a surviving domain controller in the forest by using the ntdsutil /metadata cleanup command. The risk of introducing a former FSMO role holder whose role has been seized into the forest is that the original role holder may continue to operate as before until it inbound-replicates knowledge of the role seizure. Known risks of two domain controllers owning the same FSMO roles include creating security principals that have overlapping RID pools, and other problems.
Back to the top
Transfer FSMO roles
To transfer the FSMO roles by using the Ntdsutil utility, follow these steps:

1. Log on to a Windows 2000 Server-based or Windows Server 2003-based member computer or domain controller that is located in the forest where FSMO roles are being transferred. We recommend that you log on to the domain controller that you are assigning FSMO roles to. The logged-on user should be a member of the Enterprise Administrators group to transfer Schema master or Domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the Infrastructure master roles are being transferred.
2. Click Start, click Run, type ntdsutil in the Open box, and then click OK.
3. Type roles, and then press ENTER.

Note To see a list of available commands at any one of the prompts in the Ntdsutil utility, type ?, and then press ENTER.
4. Type connections, and then press ENTER.
5. Type connect to server servername, and then press ENTER, where servername is the name of the domain controller you want to assign the FSMO role to.
6. At the server connections prompt, type q, and then press ENTER.
7. Type transfer role, where role is the role that you want to transfer. For a list of roles that you can transfer, type ? at the fsmo maintenance prompt, and then press ENTER, or see the list of roles at the start of this article. For example, to transfer the RID master role, type transfer rid master. The one exception is for the PDC emulator role, whose syntax is transfer pdc, not transfer pdc emulator.
8. At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.

Back to the top
Seize FSMO roles
To seize the FSMO roles by using the Ntdsutil utility, follow these steps:

1. Log on to a Windows 2000 Server-based or Windows Server 2003-based member computer or domain controller that is located in the forest where FSMO roles are being seized. We recommend that you log on to the domain controller that you are assigning FSMO roles to. The logged-on user should be a member of the Enterprise Administrators group to transfer schema or domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the Infrastructure master roles are being transferred.
2. Click Start, click Run, type ntdsutil in the Open box, and then click OK.
3. Type roles, and then press ENTER.
4. Type connections, and then press ENTER.
5. Type connect to server servername, and then press ENTER, where servername is the name of the domain controller that you want to assign the FSMO role to.
6. At the server connections prompt, type q, and then press ENTER.
7. Type seize role, where role is the role that you want to seize. For a list of roles that you can seize, type ? at the fsmo maintenance prompt, and then press ENTER, or see the list of roles at the start of this article. For example, to seize the RID master role, type seize rid master. The one exception is for the PDC emulator role, whose syntax is seize pdc, not seize pdc emulator.
8. At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.

Notes
* Under typical conditions, all five roles must be assigned to “live” domain controllers in the forest. If a domain controller that owns a FSMO role is taken out of service before its roles are transferred, you must seize all roles to an appropriate and healthy domain controller. We recommend that you only seize all roles when the other domain controller is not returning to the domain. If it is possible, fix the broken domain controller that is assigned the FSMO roles. You should determine which roles are to be on which remaining domain controllers so that all five roles are assigned to a single domain controller. For more information about FSMO role placement, click the following article number to view the article in the Microsoft Knowledge Base:
223346 (http://support.microsoft.com/kb/223346/ ) FSMO placement and optimization on Windows 2000 domain controllers
* If the domain controller that formerly held any FSMO role is not present in the domain and if it has had its roles seized by using the steps in this article, remove it from the Active Directory by following the procedure that is outlined in the following Microsoft Knowledge Base article:
216498 (http://support.microsoft.com/kb/216498/ ) How to remove data in active directory after an unsuccessful domain controller demotion
* Removing domain controller metadata with the Windows 2000 version or the Windows Server 2003 build 3790 version of the ntdsutil /metadata cleanup command does not relocate FSMO roles that are assigned to live domain controllers. The Windows Server 2003 Service Pack 1 (SP1) version of the Ntdsutil utility automates this task and removes additional elements of domain controller metadata.
* Some customers prefer not to restore system state backups of FSMO role-holders in case the role has been reassigned since the backup was made.
* Do not put the Infrastructure master role on the same domain controller as the global catalog server. If the Infrastructure master runs on a global catalog server it stops updating object information because it does not contain any references to objects that it does not hold. This is because a global catalog server holds a partial replica of every object in the forest.

To test whether a domain controller is also a global catalog server:

1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
2. Double-click Sites in the left pane, and then locate the appropriate site or click Default-first-site-name if no other sites are available.
3. Open the Servers folder, and then click the domain controller.
4. In the domain controller's folder, double-click NTDS Settings.
5. On the Action menu, click Properties.
6. On the General tab, view the Global Catalog check box to see if it is selected.

For more information about FSMO roles, click the following article numbers to view the articles in the Microsoft Knowledge Base:
197132 (http://support.microsoft.com/kb/197132/ ) Windows 2000 Active Directory FSMO roles
223787 (http://support.microsoft.com/kb/223787/ ) Flexible Single Master Operation transfer and seizure process

How to upgrade Windows 2000 domain controllers to Windows Server 2003

How to upgrade Windows 2000 domain controllers to Windows Server 2003
View products that this article applies to.
This article was previously published under Q325379
On This Page

* SUMMARY
o Domain and forest inventory
o Microsoft Exchange 2000 in Windows 2000 forests
+ Scenario 1: Exchange 2000 schema changes are added after you run the Windows Server 2003 adprep /forestprep command
+ Scenario 2: Exchange 2000 schema changes will be installed before the Windows Server 2003 adprep /forestprep command
+ Scenario 3: The Windows Server 2003 forestprep command was run without first running inetOrgPersonFix
o Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003
+ Upgrading the forest with the adprep /forestprep command
+ Upgrading the domain with the adprep /domainprep command
o Upgrading Windows 2000 domain controllers by using Winnt32.exe
o Dry-run upgrades in a lab environment
o Domain controllers without sufficient disk space
* REFERENCES

Expand all | Collapse all
SUMMARY
This article discusses how to upgrade Microsoft Windows 2000 domain controllers...
This article discusses how to upgrade Microsoft Windows 2000 domain controllers to Microsoft Windows Server 2003 and how to add new Windows Server 2003 domain controllers to Windows 2000 domains.
Back to the top
Domain and forest inventory
Before you upgrade Windows 2000 domain controllers to Windows Server 2003 or before you add new Windows Server 2003 domain controllers to a Windows 2000 domain, follow these steps:

1. Inventory the clients that access resources in the domain that host Windows Server 2003 domain controllers for compatibility with SMB signing:

Each Windows Server 2003 domain controller enables SMB signing in its local security policy. Make sure that all network clients that use the SMB/CIFS protocol to access shared files and printers in domains that host Windows Server 2003 domain controllers can be configured or upgraded to support SMB signing. If they cannot, temporarily disable SMB signing until updates can be installed or until the clients can be upgraded to newer operating systems that support SMB signing. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.

Action plans

The following list shows the action plans for popular SMB clients:
* Microsoft Windows Server 2003, Microsoft Windows XP Professional, Microsoft Windows 2000 Server, Microsoft Windows 2000 Professional, and Microsoft Windows 98

No action is required.
* Microsoft Windows NT 4.0

Install Service Pack 3 or later (Service Pack 6A is recommended) on all Windows NT 4.0-based computers that access domains that contain Windows Server 2003-based computers. Alternatively, temporarily disable SMB signing on Windows Server 2003 domain controllers. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
* Microsoft Windows 95

Install the Windows 9x directory service client on the Windows 95-based computers or temporarily disable SMB signing on Windows Server 2003 domain controllers. The original Win9x directory service client is available on the Windows 2000 Server CD-ROM. However, that client add-on has been replaced by an improved Win9x directory service client. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
* Microsoft Network Client for MS-DOS and Microsoft LAN Manager clients

The Microsoft Network Client for MS-DOS and the Microsoft LAN Manager 2.x network client may be used to provide access to network resources, or they may be combined with a bootable floppy disk to copy operating system files and other files from a shared directory on a file server as part of a software installation routine. These clients do not support SMB signing. Use an alternative installation method, or disable SMB signing. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
* Macintosh clients

Some Macintosh clients are not SMB signing compatible and will receive the following error message when they try to connect to a network resource:
- Error -36 I/O
Install updated software if it is available. Otherwise, disable SMB signing on Windows Server 2003 domain controllers. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
* Other third-party SMB clients

Some third-party SMB clients do not support SMB signing. Consult your SMB provider to see if an updated version exists. Otherwise, disable SMB signing on Windows Server 2003 domain controllers.
To disable SMB signing

If software updates cannot be installed on affected domain controllers that are running Windows 95, Windows NT 4.0, or other clients that were installed before the introduction of Windows Server 2003, temporarily disable the SMB service signing requirements in Group Policy until you can deploy updated client software.

You can disable SMB service signing in the following node of Default Domain Controllers policy on the domain controllers organizational unit:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server: Digitally sign communications (always)
If domain controllers are not located in the domain controller's organizational unit, you must link the default domain controller's Group Policy object (GPO) to all organizational units that host Windows 2000 or Windows Server 2003 domain controllers. Or, you can configure SMB service signing in a GPO that is linked to those organizational units.
2. Inventory the domain controllers that are in the domain and in the forest:
1. Make sure that all the Windows 2000 domain controllers in the forest have installed all the appropriate hotfixes and service packs.

Microsoft recommends that all the Windows 2000 domain controllers run the Windows 2000 Service Pack 4 (SP4) or later operating systems. If you cannot fully deploy Windows 2000 SP4 or later, all the Windows 2000 domain controllers must have an Ntdsa.dll file whose date stamp and version is later than June 4th, 2001 and 5.0.2195.3673. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
331161 (http://support.microsoft.com/kb/331161/ ) Hotfixes to install before you run adprep /Forestprep on a Windows 2000 domain controller to prepare the Forest and domains for the addition of Windows Server 2003-based domain controllers
By default, Active Directory administrative tools on Windows 2000 SP4, Windows XP, and Windows Server 2003 client computers use Lightweight Directory Access Protocol (LDAP) signing. If such computers use (or fall back to) NTLM authentication when they remotely administer Windows 2000 domain controllers, the connection will not work. To resolve this behavior, remotely administered domain controllers should have a minimum of Windows 2000 SP3 installed. Otherwise you should turn off LDAP signing on the clients that run the administration tools. For more information about LDAP, click the following article numbers to view the articles in the Microsoft Knowledge Base:
325465 (http://support.microsoft.com/kb/325465/ ) Windows 2000 domain controllers require Service Pack 3 or later when using Windows Server 2003 administration tools
The following scenarios use NTLM authentication:
* You administer Windows 2000 domain controllers that are located in an external forest connected by an NTLM (non-Kerberos) trust.
* You focus Microsoft Management Console (MMC) snap-ins against a specific domain controller that is referenced by its IP address. For example, you click Start, click Run, and then type the following command:
dsa.msc /server=ipaddress
To determine the operating system and the service pack revision level of Active Directory domain controllers in an Active Directory domain, install the Windows Server 2003 version of Repadmin.exe on a Windows XP Professional or Windows Server 2003 member computer in the forest, and then run the following repadmin command against a domain controller in each domain in the forest:
>repadmin /showattr name of the domain controller that is in the target domain ncobj:domain: /filter:"(&(objectCategory=computer)(primaryGroupID=516))" /subtree /atts:operatingSystem,operatingSystemVersion,operatingSystemServicePack

DN: CN=NA-DC-01,organizational unit=Domain Controllers,DC=company,DC=com
1> operatingSystem: Windows Server 2003
1> operatingSystemVersion: 5.2 (3718)
DN: CN=NA-DC-02,organizational unit=Domain Controllers,DC=company,DC=com
1> operatingSystem: Windows 2000 Server
1> operatingSystemVersion: 5.0 (2195)
1> operatingSystemServicePack: Service Pack 1
Note: The domain controller's attributes do not track the installation of individual hotfixes.
2. Verify the end-to-end Active Directory replication throughout the forest.

Verify that each domain controller in the upgraded forest replicates all its locally held naming contexts with its partners consistently with the schedule that site links or connection objects define. Use the Windows Server 2003 version of Repadmin.exe on a Windows XP- or Windows Server 2003-based member computer in the forest with the following arguments:

REPADMIN /REPLSUM /BYSRC /BYDEST /SORT:DELTA <-output formatted to fit on page

DestDC largest delta fails/total %% error

NA-DC-01 13d.21h:10m:10s 97 / 143 67 (8240) There is no such object...
NA-DC-02 13d.04h:11m:07s 180 / 763 23 (8524) The DSA operation...
NA-DC-03 12d.03h:54m:41s 5 / 5 100 (8524) The DSA operation...

All the domain controllers in the forest must replicate Active Directory without error, and the values in the "Largest Delta" column of the repadmin output should not be significantly greater than the replication frequency on the corresponding site links or connection objects that are used by a given destination domain controller.

Resolve all replication errors between domain controllers that have failed to inbound replicate in less than Tombstone Lifetime (TSL) number of days (by default, 60 days). If replication cannot be made to function, you may have to forcibly demote the domain controllers and remove them from the forest by using the Ntdsutil metadata cleanup command, and then promote them back into the forest. You can use a forceful demotion to save both the operating system installation and the programs that are on an orphaned domain controller. For more information about how to remove orphaned Windows 2000 domain controllers from their domain, click the following article number to view the article in the Microsoft Knowledge Base:
216498 (http://support.microsoft.com/kb/216498/ ) How to remove data in Active Directory after an unsuccessful domain controller demotion
Take this action only as a last resort to recover the installation of the operating system and the installed programs. You will lose unreplicated objects and attributes on orphaned domain controllers including users, computers, trust relationships, their passwords, groups and group memberships.

Be careful when you try to resolve replication errors on domain controllers that have not replicated inbound changes for a particular Active Directory partition for greater than tombstonelifetime number of days. When you do so, you may reanimate objects that were deleted on one domain controller but for which direct or transitive replication partners never received the deletion in the previous 60 days.

Consider removing any lingering objects that reside on domain controllers that have not performed inbound replication in the last 60 days. Alternatively, you can forcefully demote domain controllers that have not performed any inbound replication on a given partition in tombstone lifetime number of days and remove their remaining metadata from the Active Directory forest by using Ntdsutil and other utilities. Contact your support provider or Microsoft PSS for additional help.
3. Verify that the contents of the Sysvol share are consistent.

Verify that the file system portion of group policy is consistent. You can use Gpotool.exe from the Resource Kit to determine whether there are inconsistencies in policies across a domain. Use Healthcheck from the Windows Server 2003 support tools to determine whether the Sysvol share replica sets function correctly in each domain.

If the contents of the Sysvol share are inconsistent, resolve all the inconsistencies.
4. Use Dcdiag.exe from the support tools to verify that all the domain controllers have shared Netlogon and Sysvol shares. To do so, type the following command at a command prompt:
DCDIAG.EXE /e /test:frssysvol
5. Inventory the operations roles.

The schema and infrastructure operations masters are used to introduce forest and domain-wide schema changes to the forest and its domains that are made by the Windows Server 2003 adprep utility. Verify that the domain controller that hosts the schema role and infrastructure role for each domain in the forest reside on live domain controllers and that each role owner has performed inbound replication over all partitions since they were last restarted.

The DCDIAG /test:FSMOCHECK command can be used to view forest-wide and domain-wide operational roles. Operations master roles that reside on non-existent domain controllers should be seized to a healthy domain controller by using NTDSUTIL. Roles that reside on unhealthy domain controllers should be transferred if possible. Otherwise, they should be seized. The NETDOM QUERY FSMO command does not identify FSMO roles that reside on deleted domain controllers.

Verify that the schema master and each infrastructure master has performed inbound replication of Active Directory since last booted. Inbound replication can be verified by using the REPADMIN /SHOWREPS DCNAME command, where DCNAME is the NetBIOS computer name or the fully qualified computer name of a domain controller. For more information about operations masters and their placement, click the following article numbers to view the articles in the Microsoft Knowledge Base:
197132 (http://support.microsoft.com/kb/197132/ ) Windows 2000 Active Directory FSMO roles
223346 (http://support.microsoft.com/kb/223346/ ) FSMO placement and optimization on Active Directory domain controllers
6. EventLog Review

Examine the event logs on all the domain controllers for problematic events. The event logs must not contain serious event messages that indicate a problem with any of the following processes and components:
physical connectivity
network connectivity
name registration
name resolution
authentication
Group Policy
security policy
disk subsystem
schema
topology
replication engine
7. Disk Space Inventory

The volume that hosts the Active Directory database file, Ntds.dit, must have free space equal to at least 15-20% of the Ntds.dit file size. The volume that hosts the Active Directory log file must also have free space equal to at least 15-20% of the Ntds.dit file size. For additional information about how to free up additional disk space, see the "Domain Controllers Without Sufficient Disk Space" section of this article.
8. DNS Scavenging (Optional)

Enable DNS Scavenging at 7-day intervals for all DNS servers in the forest. For best results, perform this operation 61 or more days before you upgrade the operating system. This provides the DNS scavenging daemon sufficient time to garbage-collect the aged DNS objects when an offline defragmentation is performed on the Ntds.dit file.
9. Disable the DLT Server Service (Optional)

The DLT Server service is disabled on new and upgraded installations of Windows Server 2003 domain controllers. If distributed link tracking is not used, you can disable the DLT Server service on your Windows 2000 domain controllers and begin deleting DLT objects from each domain in the forest. For additional information, see the "Microsoft Recommendations for distributed link tracking" section of the following article in the Microsoft Knowledge Base:
312403 (http://support.microsoft.com/kb/312403/ ) Distributed Link Tracking on Windows-based domain controllers
10. System State Backup

Make a system state backup of at least two domain controllers in every domain in the forest. You can use the backup to recover all the domains in the forest if the upgrade does not work.

Back to the top
Microsoft Exchange 2000 in Windows 2000 forests
Notes

* If Exchange 2000 Server is installed, or will be installed, in a Windows 2000 forest, read this section before you run the Windows Server 2003 adprep /forestprep command.
* If Microsoft Exchange Server 2003 schema changes will be installed, go to the "Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003" section before you run the Windows Server 2003 adprep commands.

The Exchange 2000 schema defines three inetOrgPerson attributes with non-Request for Comment (RFC)-compliant LDAPDisplayNames: houseIdentifier, secretary, and labeledURI.

The Windows 2000 inetOrgPerson Kit and the Windows Server 2003 adprep command define RFC-complaint versions of the same three attributes with identical LDAPDisplayNames as the non-RFC-compliant versions.

When the Windows Server 2003 adprep /forestprep command is run without corrective scripts in a forest that contains Windows 2000 and Exchange 2000 schema changes, the LDAPDisplayNames for the houseIdentifier, labeledURI, and secretary attributes become mangled. An attribute becomes “mangled” if "Dup" or other unique characters are added to the beginning of the conflicted attribute name so that objects and attributes in the directory have unique names.


Active Directory forests are not vulnerable to mangled LDAPDisplayNames for these attributes in the following cases:

* If you run the Windows Server 2003 adprep /forestprep command in a forest that contains the Windows 2000 schema before you add the Exchange 2000 schema.
* If you install the Exchange 2000 schema in forest that was created where a Windows Server 2003 domain controller was the first domain controller in the forest.
* If you add Windows 2000 inetOrgPerson Kit to a forest that contains the Windows 2000 schema, and then you install Exchange 2000 schema changes, and then you run the Windows Server 2003 adprep /forestprep command.
* If you add Exchange 2000 schema to an existing Windows 2000 forest, then run Exchange 2003 /forestprep before you run the Windows Server 2003 adprep /forestprep command.

Mangled attributes will occur in Windows 2000 in the following cases:

* If you add the Exchange 2000 versions of the labeledURI, the houseIdentifier, and the secretary attributes to a Windows 2000 forest before you install the Windows 2000 inetOrgPerson Kit.
* You add the Exchange 2000 versions of the labeledURI, the houseIdentifier, and the secretary attributes to a Windows 2000 forest before you run the Windows Server 2003 adprep /forestprep command without first running the cleanup scripts.

Action plans for each scenario follow:
Scenario 1: Exchange 2000 schema changes are added after you run the Windows Server 2003 adprep /forestprep command
If Exchange 2000 schema changes will be introduced to your Windows 2000 forest after the Windows Server 2003 adprep /forestprep command is run, no cleanup is required. Go to the "Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003" section.
Scenario 2: Exchange 2000 schema changes will be installed before the Windows Server 2003 adprep /forestprep command
If Exchange 2000 schema changes have already been installed but you have NOT run the Windows Server 2003 adprep /forestprep command, consider the following action plan:

1. Log on to the console of the schema operations master by using an account that is a member of the Schema Admins security group.
2. Click Start, click Run, type notepad.exe in the Open box, and then click OK.
3. Copy the following text including the trailing hyphen after "schemaUpdateNow: 1" to Notepad.
dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace:LDAPDisplayName
LDAPDisplayName: msExchAssistantName
-

dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchLabeledURI
-

dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchHouseIdentifier
-

dn:
changetype: Modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
4. Confirm that there is no space at the end of each line.
5. On the File menu, click Save. In the Save As dialog box, follow these steps:
1. In the File name box, type the following:
\%userprofile%\InetOrgPersonPrevent.ldf
2. In the Save as type box, click All Files.
3. In the Encoding box, click Unicode.
4. Click Save.
5. Quit Notepad.
6. Run the InetOrgPersonPrevent.ldf script.
1. Click Start, click Run, type cmd in the Open box, and then click OK.
2. At a command prompt, type the following, and then press ENTER:
cd %userprofile%
3. Type the following command
c:\documents and settings\%username%>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X "domain name path for forest root domain"
Syntax notes:
* DC=X is a case-sensitive constant.
* The domain name path for the root domain must be enclosed in quotation marks.
For example, the command syntax for an Active Directory forest whose forest root domain is TAILSPINTOYS.COM would be:
c:\documents and settings\administrator>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X "dc=tailspintoys,dc=com"
Note You may need to change the Schema Update Allowed registry subkey if you receive the following error message:
Schema update is not allowed on this DC because the registry key is not set or the DC is not the schema FSMO Role Owner.
For more information about how to change this registry subkey, click the following article number to view the article in the Microsoft Knowledge Base:
285172 (http://support.microsoft.com/kb/285172/ ) Schema update require Write access to schema in Active Directory
7. Verify that the LDAPDisplayNames for the CN=ms-Exch-Assistant-Name, CN=ms-Exch-LabeledURI, and CN=ms-Exch-House-Identifier attributes in the schema naming context now appear as msExchAssistantName, msExchLabeledURI, and msExchHouseIdentifier before you run the Windows Server 2003 adprep /forestprep commands.
8. Go to the "Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003 " section to run the adprep /forestprep and /domainprep commands.

Scenario 3: The Windows Server 2003 forestprep command was run without first running inetOrgPersonFix
If you run the Windows Server 2003 adprep /forestprep command in a Windows 2000 forest that contains the Exchange 2000 schema changes, the LDAPDisplayName attributes for houseIdentifier, secretary, and labeledURI will become mangled. To identify mangled names, use Ldp.exe to locate the affected attributes:

1. Install Ldp.exe from the Support\Tools folder of the Microsoft Windows 2000 or Windows Server 2003 media.
2. Start Ldp.exe from a domain controller or member computer in the forest.
1. On the Connection menu, click Connect, leave the Server box empty, type 389 in the Port box, and then click OK.
2. On the Connection menu, click Bind, leave all the boxes empty, and then click OK.
3. Record the distinguished name path for the SchemaNamingContext attribute. For example, for a domain controller in the CORP.ADATUM.COM forest, the distinguished name path might be CN=Schema,CN=Configuration,DC=corp,DC=company,DC=com.
4. On the Browse menu, click Search.
5. Use the following settings to configure the Search dialog box:
* Base DN: The distinguished name path for the schema naming context that is identified in step 3.
* Filter: (ldapdisplayname=dup*)
* Scope: Subtree
6. Mangled houseIdentifier, secretary, and labeledURI attributes have LDAPDisplayName attributes that are similar to the following format:
LDAPDisplayName: DUP-labeledURI-9591bbd3-d2a6-4669-afda-48af7c35507d;
LDAPDisplayName: DUP-secretary-c5a1240d-70c0-455c-9906-a4070602f85f
LDAPDisplayName: DUP-houseIdentifier-354b0ca8-9b6c-4722-aae7-e66906cc9eef
7. If the LDAPDisplayNames for labeledURI, secretary, and houseIdentifier were mangled in step 6, run the Windows Server 2003 InetOrgPersonFix.ldf script to recover, and then go to the "Upgrading Windows 2000 domain controllers with Winnt32.exe" section.
1. Create a folder named %Systemdrive%\IOP, and then extract the InetOrgPersonFix.ldf file to this folder.
2. At a command prompt, type cd %systemdrive%\iop.
3. Extract the InetOrgPersonFix.ldf file from the Support.cab file that is located in the Support\Tools folder of the Windows Server 2003 installation media.
4. From the console of the schema operations master, load the InetOrgPersonFix.ldf file by using Ldifde.exe to correct the LdapDisplayName attribute of the houseIdentifier, secretary, and labeledURI attributes. To do so, type the following command, where is a case-sensitive constant and is the domain name path for the root domain of the forest:
C:\IOP>ldifde -i -f inetorgpersonfix.ldf -v -c DC=X "domain name path for forest root domain"
Syntax notes:
* DC=X is a case-sensitive constant.
* The domain name path for the forest root domain must be enclosed in quotation marks.
8. Verify that the houseIdentifier, secretary, and labeledURI attributes in the schema naming context are not "mangled" before you install Exchange 2000.

For more information about a related schema conflict with Services for UNIX version 2.0, click the following article number to view the article in the Microsoft Knowledge Base:
293783 (http://support.microsoft.com/kb/293783/ ) Cannot upgrade Windows 2000 server to Windows Server 2003 with Windows Services for UNIX 2.0 installed
Back to the top
Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003
The Windows Server 2003 adprep command that you run from the \I386 folder of the Windows Server 2003 media prepares a Windows 2000 forest and its domains for the addition of Windows Server 2003 domain controllers. The Windows Server 2003 adprep /forestprep command adds the following features:

* Improved default security descriptors for object classes
* New user and group attributes
* New Schema objects and attributes like inetOrgPerson

The adprep utility supports two command-line arguments:
adprep /forestprep: Runs forest upgrade operations.
adprep /domainprep: Runs domain upgrade operations.
The adprep /forestprep command is a one-time operation performed on the schema operation master (FSMO) of the forest. The forestprep operation must complete and replicate to the infrastructure master of each domain before you can run adprep /domainprep in that domain.

The adprep /domainprep command is a one-time operation that you run on the infrastructure operations master domain controller of each domain in the forest that will host new or upgraded Windows Server 2003 domain controllers. The adprep /domainprep command verifies that the changes from forestprep have replicated in the domain partition and then makes its own changes to the domain partition and group policies in the Sysvol share.

You cannot perform either of the following actions unless the /forestprep and the /domainprep operations have completed and replicated to all the domain controllers in that domain:

* Upgrade the Windows 2000 domain controllers to Windows Server 2003 domain controllers by using Winnt32.exe.

Note: You can upgrade the Windows 2000 member servers and computers to Windows Server 2003 member computers whenever you want.
* Promote new Windows Server 2003 domain controllers into the domain by using Dcpromo.exe.

The domain that hosts the schema operations master is the only domain where you must run both adprep /forestprep and adprep /domainprep. In all other domains, you only have to run adprep /domainprep.

The adprep /forestprep and the adprep /domainprep commands do not add attributes to the global catalog partial attribute set or cause a full synchronization of the global catalog. The RTM version of adprep /domainprep does cause a full sync of the \Policies folder in the Sysvol tree. Even if you run forestprep and domainprep several times, completed operations are performed only one time.

After the changes from adprep /forestprep and adprep /domainprep completely replicate, you can upgrade the Windows 2000 domain controllers to Windows Server 2003 by running Winnt32.exe from the \I386 folder of the Windows Server 2003 media. Also, you can add new Windows Server 2003 domain controllers to the domain by using Dcpromo.exe.
Upgrading the forest with the adprep /forestprep command
To prepare a Windows 2000 forest and domains to accept Windows Server 2003 domain controllers, follow these steps first in a lab environment, then in a production environment:

1. Make sure that you have completed all the operations in the "Forest Inventory" phase with special attention to the following items:
1. You have created system state backups.
2. All the Windows 2000 domain controllers in the forest have installed all the appropriate hotfixes and service packs.
3. End-to-end replication of Active Directory is occurring throughout the forest
4. FRS replicates the file system policy correctly throughout each domain.
2. Log on to the console of the schema operations master with an account that is a member of the Schema Admins security group.
3. Verify that the schema FSMO has performed inbound replication of the schema partition by typing the following at a Windows NT command prompt:
repadmin /showreps
(repadmin is installed by the Support\Tools folder of Active Directory.)
4. Early Microsoft documentation recommends that you isolate the schema operations master on a private network before you run adprep /forestprep. Real-world experience suggests that this step is not necessary and may cause a schema operations master to reject schema changes when it is restarted on a private network. If you want to isolate schema additions that were made by adprep, Microsoft recommends that you temporarily disable outbound replication of Active Directory with the repadmin command-line utility. To do this, following these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. Type the following, and then press ENTER:
repadmin /options +DISABLE_OUTBOUND_REPL
5. Run adprep on the schema operations master. To do so, click Start, click Run, type cmd, and then click OK. On the schema operations master, type the following command
X:\I386\adprep /forestprep
where X:\I386\ is the path of the Windows Server 2003 installation media. This command runs the forest-wide schema upgrade.

Note Events with event ID 1153 that are logged in the Directory Service event log, such as the sample that follows, can be ignored:

Event Type : Error
Event Source : NTDS General
Event Category: Internal Processing
Event ID : 1153
Date: MM/DD/YYYY
Time: HH:MM:SS AM|PM
User : Everyone Computer :
Description: Class identifier 655562 (class name msWMI-MergeablePolicyTemplate) has an invalid superclass 655560. Inheritance ignored.
6. Verify that the adprep /forestprep command successfully ran on the schema operations master. To do so, from the console of the schema operations master, verify the following items:
* The adprep /forestprep command completed without error.
* The CN=Windows2003Update object is written under CN=ForestUpdates,CN=Configuration,DC=forest_root_domain. Record the value of the Revision attribute.
* (Optional) The schema version incremented to version 30. To do so, see the ObjectVersion attribute under CN=Schema,CN=Configuration,DC=forest_root_domain.
If adprep /forestprep does not run, verify the following items:
* The fully qualified path for Adprep.exe located in the \I386 folder of the installation media was specified when adprep ran. To do so, type the following command:
x:\i386\adprep /forestprep
where x is the drive that hosts the installation media.
* The logged on user who runs adprep has membership to the Schema Admins security group. To verify this, use the whoami /all command.
* If adprep still does not work, view the Adprep.log file in the %systemroot%\System32\Debug\Adprep\Logs\Latest_log folder.
7. If you disabled outbound replication on the schema operations master in step 4, enable replication so that the schema changes that were made by adprep /forestprep can propagate. To do this, following these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. Type the following, and then press ENTER:
repadmin /options -DISABLE_OUTBOUND_REPL
8. Verify that the adprep /forestprep changes have replicated on all the domain controllers in the forest. It is useful to monitor the following attributes:
1. Incrementing the schema version
2. The CN=Windows2003Update, CN=ForestUpdates,CN=Configuration,DC=forest_root_domain or CN=Operations,CN=DomainUpdates,CN=System,DC=forest_root_domain and the operations GUIDs under it have replicated in.
3. Search for new schema classes, objects, attributes, or other changes that adprep /forestprep adds, such as inetOrgPerson. View the SchXX.ldf files (where XX is a number between 14 and 30) in the %systemroot%\System32 folder to determine what objects and attributes there should be. For example, inetOrgPerson is defined in Sch18.ldf.
9. Look for mangled LDAPDisplayNames.

If Exchange 2000 was installed before you ran the Windows Server 2003 adprep /forestprep command, see the following article in the Microsoft Knowledge Base:
314649 (http://support.microsoft.com/kb/314649/ ) Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
If you find mangled names, go to Scenario 3 of the same article.
10. Log on to the console of the schema operations master with an account that is a member of the Schema Admins group security group of the forest that hosts the schema operations master.

Upgrading the domain with the adprep /domainprep command
Run adprep /domainprep after the /forestprep changes fully replicate to the infrastructure master domain controller in each domain that will host Windows Server 2003 domain controllers. To do so, follow these steps:

1. Identify the infrastructure master domain controller in the domain you are upgrading, and then log on with an account that is a member of the Domain Admins security group in the domain you are upgrading.

Note: The enterprise administrator may not be a member of the Domain Admins security group in child domains of the forest.
2. Run adprep /domainprep on the Infrastructure master. To do so, click Start, click Run, type cmd, and then on the Infrastructure master type the following command:
X:\I386\adprep /domainprep
where X:\I386\ is the path of the Windows Server 2003 installation media. This command runs domain-wide changes in the target domain.

Note: The adprep /domainprep command modifies files permissions in the Sysvol share. These modifications cause a full synchronization of files in that directory tree.
3. Verify that domainprep completed successfully. To do so, verify the following items:
* The adprep /domainprep command completed without error.
* The CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=dn path of domain you are upgrading exists
If adprep /domainprep does not run, verify the following items:
* The logged on user who runs adprep has membership to the Domain Admins security group in the domain being you are upgrading. To do so, use the whoami /all command.
* The fully qualified path for Adprep.exe located in the \I386 directory of the installation media was specified when you ran adprep. To do so, at a command prompt type the following command:
x:\i386\adprep /forestprep
where x is the drive that hosts the installation media.
* If adprep still does not work, view the Adprep.log file in the %systemroot%\System32\Debug\Adprep\Logs\Latest_log folder.
4. Verify that the adprep /domainprep changes have replicated. To do so, for the remaining domain controllers in the domain, verify the following items:
* The CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=dn path of domain you are upgrading object exists and the value for the Revision attribute matches the value of the same attribute on the infrastructure master of the domain.
* (Optional) Look for objects, attributes or access control list (ACL) changes that adprep /domainprep added.
Repeat steps 1-4 on the infrastructure master of the remaining domains in bulk or as you add or upgrade DC's in those domains to Windows Server 2003. Now you can promote new Windows Server 2003 computers into the forest by using DCPROMO. Or, you can upgrade existing Windows 2000 domain controllers to Windows Server 2003 by using WINNT32.EXE.

Back to the top
Upgrading Windows 2000 domain controllers by using Winnt32.exe
After the changes from /forestprep and /domainprep completely replicate and you have made a decision about security interoperability with earlier-version clients, you can upgrade Windows 2000 domain controllers to Windows Server 2003 and add new Windows Server 2003 domain controllers to the domain.

The following computers must be among the first domain controllers that run Windows Server 2003 in the forest in each domain:

* The domain naming master in the forest so that you can create default DNS program partitions.
* The primary domain controller of the forest root domain so that the enterprise-wide security principals that Windows Server 2003's forestprep adds become visible in the ACL editor.
* The primary domain controller in each non-root domain so that you can create new domain-specific Windows 2003 security principals.

To do so, use WINNT32 to upgrade existing domain controllers that host the operational role you want. Or, transfer the role to a newly-promoted Windows Server 2003 domain controller. Perform the following steps for each Windows 2000 domain controller that you upgrade to Windows Server 2003 with WINNT32 and for each Windows Server 2003 workgroup or member computer that you promote:

1. Before you use WINNT32 to upgrade Windows 2000 member computers and domain controllers, remove Windows 2000 Administration Tools. To do so, use the Add/Remove Programs tool in Control Panel. (Windows 2000 upgrades only.)
2. Install any hotfix files or other fixes that either Microsoft or the administrator determines is important.
3. Check each domain controller for possible upgrade issues. To do so, run the following command from the \I386 folder of the installation media:
winnt32.exe /checkupgradeonly
Resolve any issues that the compatibility check identifies.
4. Run WINNT32.EXE from the \I386 folder of the installation media, and the restart the upgraded 2003 domain controller.
5. Lower the security settings for earlier-version clients as required.

If Windows NT 4.0 clients do not have NT 4.0 SP6 or Windows 95 clients do not have the directory service client installed, disable SMB Service signing on the Default Domain Controllers policy on the Domain Controllers organizational unit, and then link this policy to all organizational units that host domain controllers.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server: Digitally sign communications (always)
6. Verify the health of the upgrade using the following data points:
* The upgrade completed successfully.
* The hotfixes that you added to the installation successfully replaced the original binaries.
* Inbound and outbound replication of Active Directory is occurring for all naming contexts held by the domain controller.
* The Netlogon and Sysvol shares exist.
* The event log indicates that the domain controller and its services are healthy.

Note: You may receive the following event message after you upgrade:

Event Type: Error
Event Source: NTDS Backup
Event Category: Backup
Event ID: 1913
Date: Date
Time: HH:MM:SSAM|PM
User: N/A
Computer: computername
Description: Internal error: The Active Directory backup and restore operation encountered an unexpected error. Backup or restore will not succeed until this is corrected.
You can safely ignore this event message.
7. Install the Windows Server 2003 Administration Tools (Windows 2000 upgrades and Windows Server 2003 non-domain controllers only). Adminpak.msi is in the \I386 folder of the Windows Server 2003 CD-ROM. Windows Server 2003 media contains updated support tools in the Support\Tools\Suptools.msi file. Make sure that you reinstall this file.
8. Make new backups of at least the first two Windows 2000 domain controllers that you upgraded to Windows Server 2003 in each domain in the forest. Locate the backups of the Windows 2000 computers that you upgraded to Windows Server 2003 in locked storage so you do not accidentally use them to restore a domain controller that now runs Windows Server 2003.
9. (Optional) Perform an offline defragmentation of the Active Directory database on the domain controllers that you upgraded to Windows Server 2003 after the single instance store (SIS) has completed (Windows 2000 upgrades only).

The SIS reviews existing permissions on objects stored in Active Directory, and then applies a more efficient security descriptor on those objects. The SIS starts automatically (identified by event 1953 in the directory service event log) when upgraded domain controllers first start the Windows Server 2003 operating system. You benefit from the improved security descriptor store only when you log an event ID 1966 event message in the directory service event log:

Event Type: Information
Event Source: NTDS SDPROP
Event Category: Internal Processing
Event ID: 1966
Date: MM/DD/YYYY
Time: HH:MM:SS AM|PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer:
Description: The security descriptor propagator has completed a full propagation pass.
Allocated space (MB):
XX Free space (MB): XX

This may have increased free space in the Active Directory database.
User Action: Consider defragmenting the database offline to reclaim the free space that may be available in the Active Directory database. For more information, see Help and Support Center at http://support.microsoft.com.
This event message indicates that the single instance store operation has completed and serves as a queues the administrator to perform of offline defragmentation of the Ntds.dit using NTDSUTIL.EXE.

The offline defragmentation can reduce the size of a Windows 2000 Ntds.dit file by up to 40%, improves Active Directory performance, and updates the pages in the database for more efficient storage of Link Valued attributes. For more information about how to defragment the Active Directory database, click the following article number to view the article in the Microsoft Knowledge Base:
232122 (http://support.microsoft.com/kb/232122/ ) Performing offline defragmentation of the Active Directory database
10. Investigate the DLT Server Service. Windows Server 2003 domain controllers disable the DLT Server service on fresh and upgrade installs. If Windows 2000 or Windows XP clients in your organization use the DLT Server service, use Group Policy to enable the DLT Server service on new or upgraded Windows Server 2003 domain controllers. Otherwise, incrementally delete distributed link tracking objects from Active Directory. For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
312403 (http://support.microsoft.com/kb/312403/ ) Distributed Link Tracking on Windows-based domain controllers
315229 (http://support.microsoft.com/kb/315229/ ) Text version of Dltpurge.vbs for Microsoft Knowledge Base article Q312403
If you bulk delete thousands of DLT objects or other objects, you may block replication because of a lack of version store. Wait tombstonelifetime number of days (by default, 60 days) after you delete the last DLT object and for garbage collection to complete, then use NTDSUTIL.EXE to perform an offline defragmentation of the Ntds.dit file.
11. Configure the best practice organizational unit structure. Microsoft recommends that administrators actively deploy the best practice organizational unit structure in all the Active Directory domains, and after they upgrade or deploy Windows Server 2003 domain controllers in Windows Domain mode, redirect the default containers that earlier-version APIs use to create users, computers and groups to an organizational unit container that the administrator specifies.

For additional information about the best practice organizational unit structure, view the "Creating an Organizational Unit Design" section of the "Best Practice Active Directory Design for Managing Windows Networks" white paper. To view the white paper, visit the following Microsoft Web site:
http://technet.microsoft.com/en-us/library/bb727085.aspx (http://technet.microsoft.com/en-us/library/bb727085.aspx)
For more information about changing the default container where users, computers and groups that earlier-version APIs create are located, click the following article number to view the article in the Microsoft Knowledge Base:
324949 (http://support.microsoft.com/kb/324949/ ) Redirecting the users and computers containers in Windows Server 2003 domains
12. Repeat steps 1 through 10 as required for each new or upgraded Windows Server 2003 domain controller in the forest and step 11 (Best Practice organizational unit structure) for each Active Directory domain.

In Summary:
* Upgrade Windows 2000 Domain controllers with WINNT32 (from the slipstreamed installation media if used)
* Verify the hotfixed files have been installed on the upgraded computers
* Install any required hotfixes not contained on installation media
* Verify the health on new or upgraded servers ( AD, FRS, Policy etc)
* Wait 24 hours after OS upgrade then offline defrag (optional)
* Start the DLT Service if you must, otherwise delete DLT objects using q312403 / q315229 post forest wide domainpreps
* Perform offline defrag 60+ days (tombstone lifetime and garbage collection # of days) after deleting DLT objects

Back to the top
Dry-run upgrades in a lab environment
Before you upgrade Windows domain controllers to a production Windows 2000 domain, validate and refine your upgrade process in the lab. If the upgrade of a lab environment that accurately mirrors the production forest performs smoothly, you can expect similar results in production environments. For complex environments, the lab environment must mirror the production environment in the following areas:

* Hardware: computer type, memory size, page file placement, disk size, performance and raid configuration, BIOS and firmware revision levels
* Software: client and server operating system versions, client and server applications, service pack versions, hotfixes, schema changes, security groups, group memberships, permissions, policy settings, object count type and location, version interoperability
* Network infrastructure: WINS, DHCP, link speeds, available bandwidth
* Load: Load simulators can simulate password changes, object creation, Active Directory replication, logon authentication and other events. The goal is not to reproduce the scale of the production environment. Instead, the goals are to discover the costs and frequency of common operations and to interpolate their effects (name queries, replication traffic, network bandwidth, and processor consumption) on the production environment based on your current and future requirements.
* Administration: tasks performed, tools used, operating systems used
* Operation: capacity, interoperability
* Disk Space: Note the starting, peak and ending size of the operating system, Ntds.dit and Active Directory log files on global catalog and non-global catalog domain controllers in each domain after each of the following operations:
1. adprep /forestprep
2. adprep /domainprep
3. Upgrading Windows 2000 domain controllers to Windows Server 2003
4. Performing offline defragmentation after version upgrades

An understanding of the upgrade process and complexity of the environment combined with detailed observation determines the pace and degree of care that you apply to upgrading production environments. Environments with a small number of domain controllers and Active Directory objects connected over high availability wide area network (WAN) links might upgrade in only a few hours. You may have to take more care with enterprise deployments that have hundreds of domain controllers or hundreds of thousands of Active Directory objects. In such cases, you may want to perform the upgrade over the course of several weeks or months.

Use "Dry-run" upgrades in the lab to perform the following tasks:

* Understand the inner workings of the upgrade process and the associated risks.
* Expose potential problem areas for the deployment process in your environment.
* Test and develop fall-back plans in case the upgrade does not succeed.
* Define the appropriate level of detail to apply to the upgrade process for the production domain.

Back to the top
Domain controllers without sufficient disk space
On domain controllers with insufficient disk space, use the following steps to free up additional disk space on the volume that hosts the Ntds.dit and Log files:

1. Delete the unused files including *.tmp files or cached files that internet browsers use. To do so, type the following commands (press ENTER after each command):
cd /d drive\
del *.tmp /s
2. Delete any user or memory dump files. To do so, type the following commands (press ENTER after each command):
cd /d drive\
del *.dmp /s
3. Temporarily remove or relocate files that you can access from other servers or easily reinstall. Files that you can remove and easily replace include ADMINPAK, Support Tools, and all the files in the %systemroot%\System32\Dllcache folder.
4. Delete old or unused user profiles. To do so, click Start, right-click My Computer, click Properties, click the User Profiles tab, and then delete all the profiles that are for old and unused accounts. Do not delete any profiles that may be for service accounts.
5. Delete the symbols at %systemroot%\Symbols. To do so, type the following command:
rd /s %systemroot%\symbols
Depending on whether the servers have a full or small symbol set, this may gain approximately 70 MB to 600 MB.
6. Perform an offline defragmentation. An offline defragmentation of the Ntds.dit file may free up space but temporarily requires double the space of the current DIT file. Perform the offline defrag by using other local volumes if one is available. Or, use space on a best connected network server to perform the offline defragmentation. If the disk space is still not sufficient, incrementally delete unnecessary user accounts, computer accounts, DNS records and DLT objects from Active Directory.

Note: Active Directory does not delete objects from the database until tombstonelifetime number of days (by default, 60 days) have passed and the garbage collection completes. If you reduce tombstonelifetime to a value lower than end-to-end replication in the forest, you may cause inconsistencies in Active Directory.

Friday, December 26, 2008

How to fix the Firefox memory leak (Firefox hack)

How to fix the Firefox memory leak (Firefox hack)

Posted in Firefox and Greasemonkey, Popular Posts, Technology by engtech on December 2nd, 2006

Firefox memory leak? It doesn’t have one. Unfortunately, because of the way it’s configured to run out of the box it *looks* like it has one.

Follow these simple steps to get your Firefox memory usage under control.

These configuration changes are a trade-off between internet browsing speed and memory usage. They are most useful if you are multitasking and need Firefox to be less of a memory hog while using other applications.

#1: about:config

Type “about:config” into your address bar to access the hidden configuration options for Firefox.

firefox-memory-leak.png

#2: browser.cache.memory.capacity

Controls how much memory is used to cache pages.

Right click on the page and choose New then Integer and create an integer called browser.cache.memory.capacity and set it to a low number. This controls how many kilobytes of memory are used for the browser’s cache.

NOTE: number in screenshot is too small. Aim for 80% of whatever the default is.

firefox-memory-leak3.png

#3: browser.cache.disk.capacity

Controls how much disk space is used to cache pages in kilobytes.

Set browser.cache.disk.capacity to between 5000 or 15000.

128MB to 512M -> 5000.
512BM to 1GB of RAM -> use 15000

firefox-memory-leak6.png

#4: config.trim_on_minimize (optional)

Configure Firefox to swap memory to disk when minimized. This will make Firefox less responsive if you minimize/maximize a lot, but it is good if you need to free memory while multi-tasking to other applications.

Right click on the page and choose New then Boolean and create a boolean called config.trim_on_minimize and set it to true. Now when you minimize the window it will free up memory.

firefox-memory-leak4.png

#5: network.prefetch-next

Network link prefetch will download all pages with the rel=”prefetch” tag. This uses up more memory than you would otherwise think.

Set network.prefetch-next to false.

firefox-memory-leak2.png

#6: browser.sessionhistory.max_total_viewers

This controls how many pages of history are kept in the back/forward buttons. Lower the value to something acceptable. If you do not use back/forward often then you can set this very low.
Set browser.sessionhistory.max_total_viewers to a low number.

firefox-memory-leak5.png

Related Posts

Further Reading

Ryan at CyberNet installs 200 Firefox extensions (via Rooster) and checks memory usage. It jumps from 145 MB to 195 MB after two hours (note that this is a worst case scenario).

Mozillazine article on reducing memory use in Firefox.

List of popular extensions that have memory problems.

Leak Monitor extension for detecting memory leaks.