Error message when you try to set an IP address on a network adapter.
When you trying to set the IP address on a network adapter, you may receive the following error message:
The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter Name of adapter. Name of adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. If the same address is assigned to both adapters and they become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the advanced dialog box?
CAUSE
A network adapter with the same IP address is in the registry but is hidden in Device Manager. This can occur when you move a network card from one PCI slot to another PCI slot.
The DevCon utility is a command-line utility that acts as an alternative to Device Manager. When you use DevCon, you can enable, disable, restart, update, remove, and query individual devices or groups of devices. To use DevCon, follow these steps:
1.
Download the DevCon tool by clicking the following article number to view the article in the Microsoft Knowledge Base:
311272 (http://support.microsoft.com/kb/311272/) The DevCon command-line utility functions as an alternative to Device Manager
2.
Unpack the 32-bit or 64-bit DevCon tool binary to a local folder.
3.
Click Start, click Run, then type cmd and press ENTER.
4.
Type CD:path_to_binaries to navigate to the devcon.exe is located.
5.
Use the following syntax to find installed network adapters: devcon findall =net or devcon listclass net Note In the output of the previous commands, there is a line for the ghosted network adapter that is similar to the following:
PCIVEN_10B7&DEV_9200&SUBSYS_00D81028&REV_784&19FD8D60&0&58F0: 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible)
6.
Remove the ghosted device by typing the following syntax:
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.
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
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.
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:
a.
In the File name box, type the following:
%userprofile%InetOrgPersonPrevent.ldf
b.
In the Save as type box, click All Files.
c.
In the Encoding box, click Unicode.
d.
Click Save.
e.
Quit Notepad.
6.
Run the InetOrgPersonPrevent.ldf script.
a.
Click Start, click Run, type cmd in the Open box, and then click OK.
b.
At a command prompt, type the following, and then press ENTER:
cd %userprofile%
c.
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 settingsadministrator>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.
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 SupportTools 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.
a.
On the Connection menu, click Connect, leave the Server box empty, type 389 in the Port box, and then click OK.
b.
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:
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.
a.
Create a folder named %Systemdrive%IOP, and then extract the InetOrgPersonFix.ldf file to this folder.
b.
At a command prompt, type cd %systemdrive%iop.
c.
Extract the InetOrgPersonFix.ldf file from the Support.cab file that is located in the SupportTools folder of the Windows Server 2003 installation media.
d.
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 <X> is a case-sensitive constant and <dn path for forest root domain> 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
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:
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:
a.
You have created system state backups.
b.
All the Windows 2000 domain controllers in the forest have installed all the appropriate hotfixes and service packs.
c.
End-to-end replication of Active Directory is occurring throughout the forest
d.
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 SupportTools 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:
a.
Click Start, click Run, type cmd, and then click OK.
b.
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:I386adprep /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 : <some DC>
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:i386adprep /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%System32DebugAdprepLogsLatest_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:
a.
Click Start, click Run, type cmd, and then click OK.
b.
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:
a.
Incrementing the schema version
b.
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.
c.
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:I386adprep /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:i386adprep /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%System32DebugAdprepLogsLatest_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.
Inventory the domain controllers that are in the domain and in the forest
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 http://support.microsoft.com/kb/331161/
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
The DCDIAG /test:FSMOCHECK command can be used to view forest-wide and domain-wide operational roles.
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.
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
Disk Space Inventory
DNS Scavenging (Optional)
Enable DNS Scavenging at 7-day intervals for all DNS servers in the forest.
So you and your friends have a wild party and you wake up in the morning to realize someone has changed the admin password on your beloved mac and you can no longer access your computer. No problem, you can just pop in the OS X DVD that came with your computer and reset the password….but wait, that’s missing too.
Here’s how to reset your OS X password without an OS X CD. You need to enter terminal and create a new admin account:
Reboot
Hold apple + s down after you hear the chime.
When you get text prompt enter in these terminal commands to create a brand new admin account (hitting return after each line):
mount -uw /
rm /var/db/.AppleSetupDone
shutdown -h now
After rebooting you should have a brand new admin account. When you login as the new admin you can simply reset the old account password or delete the old one and you’re good to go again!
Change to Graphical User Mode from Text
Login as root and type startx, if that doesnt work try Xconfigurator and follow the prompts.
Navigation:
Move back: cd / cd volumes/
virtual filesystem: cd /vmfs
copy file = cp
copy file to directory shiraj: cp filename /home/shiraj
df -h = listfile, show size of disk, and available
du -hs = show disk size
du = directory list expanded
move/rename: mv to rename filename test to test.bak: mv test test.bak
File Attribute and permission:
List: ls, ls /home, ls -alF
list folder with: ls -alF drwxr-xr-x 4 root wheel 136 29 Sep 2006 xgrid/
drwxr -xr -x : d is for directory, rwx = user permission, r -x= group permission, r -x=all
DISKS fdisk -l – this will display list of drives.
USING VI FILE EDITING
edit or view file test.cfg: vi test.cfg
insert to start editing: i
to out of edit mode: esc
close (semicolon): : close quit yes: :q! write save quite and yes: :wq! to check large log file name test: tail
test last 30 line of filename test: tail -30 test
Back to the top
Back to the top