Best Networks Inc - Your resource for Information Technology

Windows XP, Windows Vista and Windows 7 all have a normal set of shortcuts that I normally use in a day by day bases. When we are active in a remote session these keys are no longer the same! 

Here is a combination list of these shortcuts.   Knowing them will make your life a bit easier. 

• CTRL+ALT+END: I use this one to open the Microsoft Windows Task Manager. Locally the key is (CTRL+ALT+DEL)
• ALT+PAGE UP: Switch between programs from left to right (CTRL+PAGE UP). Locally I cycle thru these key combination (ALT+TAB)
• ALT+PAGE DOWN: Switch between programs from right to left (CTRL+PAGE DOWN). Locally I cycle thru these key combination (ALT+TAB)
• ALT+INSERT: Cycle through the programs in most recently used order (ALT+TAB)
• ALT+HOME: Display the Start menu (CTRL+ESC)
• CTRL+ALT+BREAK: Switch the client computer between a window and a full screen
• ALT+DELETE: Display the Windows menu
• CTRL+ALT+Minus sign (-): Place a snapshot of the entire client window area on the Terminal server clipboard and provide the same functionality as pressing ALT+PRINT SCREEN on a local computer (ALT+PRT SC)
• CTRL+ALT+Plus sign (+): Place a snapshot of the active window in the client on the Terminal server clipboard and provide the same functionality as pressing PRINT SCREEN on a local computer (PRT SC)

Windows cannot access the specified device, path, or file

Best Networks Inc. 

www.BestNetworks.NET

Cesar Lopez

I had issues with a Windows Server 2003 R2 running in Terminal Server Mode and accessing an executable from another windows 2003 R2 Server.

Same configuration is currently running in another Windows 200 Terminal Server – So the issue must be some type of restriction imposed by Windows 2003 R2.  Here are the details of the problem / solving steps.

• Drive is mapped as follows G: = \\servername\vol1.  Users have Read and Execute access to the folder and file at G\Program\Name.exe

• Program was installed in terminal server mode as always: User /installed and user /execute
• Created a shortcut in the desktop- within a Terminal Server Virtual Session
• As we tried to execute the shortcut I get the following error:

“Windows cannot access the specified device, path, or file.  You may not have the appropriate permissions to access the item”

I have found the solution is a two step process:

1. We need to make changes to the Internet Explorer
2. And, we also need to make changes to the Group Policies as follows.

First, in the Internet Explorer, we need to trust the File Server as it is part of the Intranet – the executable file sits in another local server.

Open Internet Explorer and go to: Tools, Internet Options, Security and Local Intranet

Select Sites and add the name of the other File Server as follows //ServerName to the list.  Note that if you go back and check the server was added to the list you will notice the “//” are now gone.

Second, with this change we have passed the first error.  However, an Open File – Security Warning is now present.

 “The publisher could not be verified.  Are you sure you want to run this software?”

You get this warning if you execute the program using the UNC path or a mapped drive.

Open Start, Run and type gpedit.msc, Click OK

• User Configuration
• Administrative Templates
• Windows Components
• Attachment Manager
  • Add .exe to the Inclusion list for moderate risk file types setting. You can also add other extensions if needed.

This will disable the “Publisher Could Not Be Verified,” messages from appearing for the specified file type.

When the user attempts to add the 11^th computer or server to the Domain he/she will get one of the following messages.

When attempting to add a workstation to a Windows 2000 domain and the workstation is a Windows NT 4.0 or Windows NT 4.0 Server: 

The machine account for this computer either does not exist or is unavailable.

IF the workstation you are adding is a Windows 2000 Pro or a windows 2000 Server then the following message is displayed.

Your computer could not be joined to the domain. You have exceeded the maximum number of computer accounts you are allowed to create in this domain. Contact your system administrator to have this limit reset or increased.

According to MSKB articles 251335 and 314462, there are three Methods to change this default.

1. Pre-Create the User’s Computer Account
2. Grant the “Create Computer Objects” and “Delete Computer Objects” Access Control Entries (ACEs) to the User
3. Override the Default Limit of the Number of Computers an Authenticated User Can Join to a Domain

Method 1:

1. From the Active Directory Users and Computers snap-in, right-click the container where the account resides.
2. Click New, and then click Computer.
3. In the Computer name box, type the name of the Windows 2000-based computer that you want to add to the domain.
   Make sure the computer’s name is also entered in the Computer name (pre-Windows 2000) box (this should occur automatically).
4. Click Change. Select the user or group that will be joining this computer to the domain, and then click OK.
5. If you want Windows NT 4.0 and previous operating systems to use this computer name object, click to select the Allow pre-Windows 2000 computers to use this account check box, and then click OK.

Method 2:

1. From the Active Directory Users and Computers snap-in, click Advanced Features on the View menu so that the Security tab is exposed when you click Properties.
2. Right-click the Computers container, and then click Properties.
3. On the Security tab, click Advanced.
4. On the Permissions tab, click Authenticated Users, and then click View/Edit.

   NOTE: If the Authenticated Users group is not listed, click Add and add it to the list of permission entries.

5. Make sure the This object and all child objects option is displayed in the Apply onto box.
6. From the Permissions box, click to select the Allow check box next to the Create Computer Objects and Delete Computer Objects ACEs, and then click OK.

Method 2:

You can override the default limit, using either of the following methods:

• Use the Ldp (Ldp.exe) tool included in the Microsoft Windows 2000 Resource Kit.
• Use an Active Directory Services Interface (ADSI) script to increase or decrease the value of the Active Directory ms-DS-MachineAccountQuota attribute. To do this:

1. Install the Windows Support tools if they have not already been installed.
2. Run Adsiedit.msc as an administrator of the domain.
3. Expand the Domain NC node. This node contains an object that begins with “DC=” and reflects the correct domain name. Right-click this object, and then click Properties.
4. In the Select which properties to view box, click Both.
5. In the Select a property to view box, click ms-DS-MachineAccountQuota.
6. In the Edit Attribute box, type a number. This number represents the number of workstations that you want users to be able to maintain concurrently.
7. Click Set, and then click OK.

Note: the Key to this change is located in the properties of the Object ms-DS-MachineAccountQuota.  One option is to increase the quota, an even better option (depending on the knowledge level on-site) is to clear it to set the number of workstation that can be added by the user to unlimited.

Resources:

check out the article “Recipe 8.11. Changing the Maximum Number of Computers a User Can Join to the Domain,” from the CodeIdol.com.

Using the Active Directory Service Interfaces Editors (ADSI Edit)

To run ADSI Edit on Windows Server 2003 or Windows XP machines, you’ll need to install Windows Server 2003 Support Tools, which you’ll find on the Windows Server 2003 CD or the Microsoft Download Center. If you’re running Windows Server 2008, ADSI Edit is installed as part of the Active Directory Domain Services (AD DS) role, which makes the server a domain controller. You can also install the Remote Server Administration Tool (RSAT) on servers that aren’t domain controllers.  On machines running Windows Vista SP1 or Windows 7, you must install RSAT to use ADSI Edit.

http://support.microsoft.com/kb/314462/EN-US/

ADSI Edit (adsiedit.msc)

Updated: March 19, 2010

Applies To: Windows SBS 2008, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

Active Directory® Service Interfaces Editor (ADSI Edit) is a Lightweight Directory Access Protocol (LDAP) editor that you can use to manage objects and attributes in Active Directory. ADSI Edit (adsiedit.msc) provides a view of every object and attribute in an Active Directory forest. You can use ADSI Edit to query, view, and edit attributes that are not exposed through other Active Directory Microsoft Management Console (MMC) snap-ins: Active Directory Users and Computers, Active Directory Sites and Services, Active Directory Domains and Trusts, and Active Directory Schema.

This topic includes the following sections:

• Installing ADSI Edit
• Using ADSI Edit
• Adding ADSI Edit to MMC
• Missing Commands
• Other Topics with ADSI Edit Usage Scenarios

Installing ADSI Edit

To install ADSI Edit on computers running Windows Server® 2003 or Windows® XP operating systems, install Windows Server 2003 Support Tools from the Windows Server 2003 product CD or from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=100114). For more information about how to install Windows Support Tools from the product CD, see Install Windows Support Tools (http://go.microsoft.com/fwlink/?LinkId=62270).

On servers running Windows Server 2008 or Windows Server 2008 R2, ADSI Edit is installed when you install the Active Directory Domain Services (AD DS) role to make a server a domain controller. You can also install Windows Server 2008 Remote Server Administration Tools (RSAT) on domain member servers or stand-alone servers. For specific instructions, see Installing or Removing the Remote Server Administration Tools Pack (http://go.microsoft.com/fwlink/?LinkId=143345).

To install ADSI Edit on computers running Windows Vista® with Service Pack 1 (SP1) or Windows 7, you must install RSAT. For more information and to download RSAT, see article 941314 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=116179).

regsvr32 adsiedit.dll

Using ADSI Edit

http://technet.microsoft.com/en-us/library/cc773354(WS.10).aspx

ADSI Edit (Adsiedit.msc) is an MMC snap-in. You can add the snap-in to any .msc file through the Add/Remove Snap-in menu option in MMC, or just open the Adsiedit.msc file from Windows Explorer. The following figure illustrates the ADSI Edit interface. In the console tree on the left, you can see the major partitions Domain, Configuration, and Schema. The figure shows the Builtin container of the Contoso.com domain selected. In the details pane on the right, you can see the Builtin groups of Active Directory.

ADSI Edit Node

To view the following commands, in the console tree click the ADSI Edit node, click the Action menu, and then click one of the following:

• Connect To
• Refresh

Connect To

The Connection Settings dialog box appears. You can use the Connection Settings dialog box to create a connection point to an object in Active Directory. The following text boxes are located in the Connection Settings dialog box:

Name. You should not change the text in this box because it might cause an error when you attempt to make a connection. The text in this box is updated automatically, if necessary, when you configure or select a Connection Point.

Path. Displays the URL for the selected object. It cannot be edited. If the path is not correct, click Cancel, and then select the correct object.

Connection Point Section

Click either Select or type a Distinguished Name or Naming Context or Select a well known Naming Context.

• If you click the Select or type a Distinguished Name or Naming Context radio button, type the distinguished name of the object that will be the connection point in Active Directory. For example, if your domain name is contoso.com and you want to connect to the Users container, type cn=users,dc=contoso,dc=com.
• If you click the Select a well known Naming Context radio button, select the directory partition that will be the connection point in Active Directory in the list of partitions in the selection menu.

Computer Section

Specifies whether you connect to the local computer or a remote computer. Click either Default (domain or server that you are logged in to) or Select or type a domain or server. You can enter the domain name or computer name in Domain Name System (DNS) format or NetBIOS format, or you can enter an IP address.

Advanced Button

Click the Advanced button to specify alternate credentials or alternate port numbers or to change the protocol that is used to connect to Active Directory. The Advanced dialog box contains the following text boxes:

Specify Credentials. Use this box to specify alternate credentials. Unless otherwise specified, the currently logged-on user’s credentials are used.

Port Number. Type a port number if you do not want to use the default port for the LDAP or the LDAP Global Catalog protocol. The default LDAP port is 389. The default port for the Global Catalog is 3268.

Protocol Section

Click either LDAP or Global Catalog. The URL in Path might change, based on your selection. LDAP is used by default. To view the Path box, on the Advanced tab, click OK or Cancel.

Refresh

To update the object from Active Directory, right-click an object, and then click Refresh. The Refresh command removes the current objects in the container and repopulates the container with updated information from Active Directory.

Directory Partition Node

To view the following commands, select the directory partition node that you want to manage (that is, Domain, Configuration, and Schema), click the Action menu, and then click one of the following:

• Settings
• Remove
• Update Schema Now
• New
• Refresh

Settings

The Connection Settings dialog box appears, which provides the same configuration options as previously discussed in the Connect To section.

Remove

Removes the connection point that connects ADSI Edit to a directory partition or container within Active Directory. This command affects only what is shown in the ADSI Edit console. To remove objects from Active Directory, use the Delete command.

Update Schema Now

Reloads the schema information from Active Directory into the local computer’s cache.

New

Click Query to create a new query. For more information about creating LDAP queries, see LDAP Query Basics (http://go.microsoft.com/fwlink/?LinkId=143553).

Refresh

To update the object from Active Directory, right-click an object, and then click Refresh. The Refresh command removes the current objects in the container and repopulates the container with updated information from Active Directory.

Object Node

To view the following commands, click an object in the details pane (for example, Account Operators is an object in the previous figure), click the Action menu, and then click one of the following:

• Move
• New Connection from Here
• New
• Delete
• Rename
• Refresh

Move

Moves the object to another container in Active Directory. Opens a dialog box that you can use to select the destination container.

New Connection From Here

Creates a new connection point node and adds it to the console.

New

The New menu command reveals another menu that contains the Object command, which creates a new child object in the selected container. This command opens a set of chained dialog boxes that begins with the class of the object. If you do not have the appropriate permissions to create an object in the selected container, no classes will be listed. After you select a class, a dialog box opens for each required attribute. In the final dialog box, click More to view and edit any optional attributes.

Delete

Deletes the selected object from Active Directory. A dialog box appears asking you to confirm the deletion. This command does not appear in the menu if you do not have permissions to delete an object from Active Directory.

Rename

Changes the name of the object in Active Directory.

Refresh

To update the object from Active Directory, right-click an object, and then click Refresh. The Refresh command removes the current objects in the container and repopulates the container with updated information from Active Directory.

Adding ADSI Edit to MMC

If you are running ADSI Edit on a computer that is not logged on to a domain or if you want to create a customized MMC, you may want to add the ADSI Edit snap-in to the console.

To add the ADSI Edit Snap-in to MMC

1. Open your existing console or create a new console. To create a new console, click Start, click Run, type mmc, and click OK, or at a command line, type mmc, and then press ENTER.
2. Click Add/Remove Snap-in, and then click Add.
3. In the Add Standalone Snap-in dialog box, click ADSI Edit in the list. If ADSI Edit does not appear here, see Installing ADSI Edit at the beginning of this topic.
4. Click Add, click Close, and then click OK.

Missing Commands

The Action menus in MMC are context sensitive. If you do not have permission to perform an action, the action might not appear in the menu.

Other Topics with ADSI Edit Usage Scenarios

Although ADSI Edit is not intended for regular management of your Active Directory environment, there are instances in which you may need to use it. The following topics include procedures that use ADSI Edit.

• Weaken security using ADSI Edit (http://go.microsoft.com/fwlink/?LinkId=143425)
• Manage an AD LDS Instance Using ADSI Edit (http://go.microsoft.com/fwlink/?LinkId=143426)
• Using ADSI Edit to Edit Active Directory Attributes (http://go.microsoft.com/fwlink/?LinkId=143427)
• Article 822444 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=143428)
• Step 1: Create a PSO (http://go.microsoft.com/fwlink/?LinkId=143555)

Creating additional domain controllers

If you already have one domain controller in a domain, you can add additional domain controllers to the domain to improve the availability and reliability of network services. Adding additional domain controllers can help provide fault tolerance, balance the load of existing domain controllers, and provide additional infrastructure support to sites.
More than one domain controller in a domain makes it possible for the domain to continue to function if a domain controller fails or must be disconnected. Multiple domain controllers can also improve performance by making it easier for clients to connect to a domain controller when logging on to the network. You can add additional domain controllers over the network or from backup media.
Before adding domain controllers you should thoroughly understand Active Directory and the requirements necessary to set up additional domain controllers in an existing domain. For more information, see Checklist: Creating an additional domain controller in an existing domain and Create an additional domain controller.

Using backup media to create additional domain controllers

With Windows 2000, the only way you can create an additional domain controller in an existing domain is by replicating the entire directory database to the new domain controller. With low network bandwidth or a large directory database, this replication can take hours or days to complete. With servers running Windows Server 2003, you can create an additional domain controller using a restored backup taken from a domain controller running Windows Server 2003. This backup can be stored on any backup media (tape, CD, or DVD) or a shared resource.
Using restored backup files to create an additional domain controller will greatly reduce the network bandwidth used when installing Active Directory over a shared resource; however, network connectivity is still necessary so that all new objects and recent changes to existing objects are replicated to the new domain controller.
It is recommended that you use the most recent backup available. Older backups require more network bandwidth for replication. The backup used cannot be older than the tombstone lifetime of the domain, which is set to a default value of 60 days (180 days in a forest that is created on a server running Windows Server 2003 with Service Pack 1 [SP1]).
If a domain controller that was backed up contained an application directory partition, it will not be restored on the new domain controller. To manually create an application directory partition on a new domain controller, see Create or delete an application directory partition.
When adding an additional domain controller using backup media, a System State backup taken only from a domain controllers running Windows Server 2003 can be used once it has been restored. For more information about how to restore a System State backup, see Restore System State data.
For general information about restoring backups, see Authoritative, primary, and normal restores.

 
Checklist: Creating an additional domain controller in an existing domain

Checklist: Creating an additional domain controller in an existing domain

Step Reference
(Optional) Review concepts about creating additional domain controllers over the network or by using backup media. Creating an additional domain controller

(Optional) Review concepts about security and other options available when using the Active Directory Installation Wizard. Using the Active Directory Installation Wizard

Verify that the server on which you will be installing Active Directory has an NTFS partition. Reformatting or converting a partition to use NTFS

(Optional) Review the role of a domain controller. Domain controllers

Verify that you are a member of the Domain Admins group in the domain where you will be adding the domain controller. Default groups

Verify that DNS is properly configured before installing Active Directory. Checklist: Verifying DNS before installing Active Directory

Create the domain controller. Create an additional domain controller

 
Using the Active Directory Installation Wizard
Updated: January 21, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Using the Active Directory Installation Wizard
The Active Directory Installation Wizard installs and configures domain controllers, which provide network users and computers access to the Active Directory directory service. You can install Active Directory on any member server (except those with restrictive license agreements) using the Active Directory Installation Wizard. Using the wizard, you will define one of the following roles for the new domain controller:
• New forest (also a new domain)

For a checklist about creating a new forest, see Checklist: Creating a new forest.
• New child domain

For a checklist about creating a child domain, see Checklist: Creating a new child domain.
• New domain tree in an existing forest

For a checklist about creating a new domain tree, see Checklist: Creating a new domain tree.
• An additional domain controller in an existing domain.  This One! We will follow these steps if there is a domain ctrl in place – Cesar
For a checklist about creating an additional domain controller, see Checklist: Creating an additional domain controller in an existing domain.
Before using the Active Directory Installation Wizard, consider DNS configuration and support for existing applications.
DNS configuration
By default, the Active Directory Installation Wizard attempts to locate an authoritative DNS server for the new domain from its list of configured DNS servers that will accept a dynamic update of a service (SRV) resource record. If found, all the appropriate records for the domain controller are automatically registered with the DNS server after the domain controller is restarted.
If a DNS server that can accept dynamic updates is not found, either because the DNS server does not support dynamic updates or dynamic updates are not enabled for the domain, then the Active Directory Installation Wizard will take the following steps to ensure that the installation process is completed with the necessary registration of the SRV resource records:
1. The DNS service is installed on the domain controller and is automatically configured with a zone based on the Active Directory domain.

For example, if the domain that you chose for your first domain in the forest is example.microsoft.com, then a zone rooted at the DNS domain name of example.microsoft.com is added and configured to use the DNS Server service on the new domain controller.
2. A text file containing the appropriate DNS resource records for the domain controller is created.

The file called Netlogon.dns is created in the systemroot\System32\Config folder and contains all the records needed to register the resource records of the domain controller. Netlogon.dns is used by the Net Logon service and supports Active Directory on servers running non-Windows Server 2003 DNS.

If you are using a DNS server that supports the SRV resource record but does not support dynamic updates (such as a UNIX-based DNS server or a Windows NT DNS server), you can import the records in Netlogon.dns into the appropriate primary zone file to manually configure the primary zone on that server to support Active Directory.
If no DNS servers are available on the network, you can choose the option to automatically install and configure a local DNS server when you install Active Directory using the Active Directory Installation Wizard. The DNS server will be installed on the server on which you are running the wizard, and the server’s preferred DNS server setting will be configured to use the new local DNS server.
Before running the Active Directory Installation Wizard, ensure that the authoritative DNS zone allows dynamic updates and that the DNS server hosting the zone supports the DNS SRV resource record. For more information, see Checklist: Verifying DNS before installing Active Directory.
For more information, see Configure a DNS server for use with Active Directory. For general information about DNS integration with Active Directory, see DNS integration.
Support for existing applications
On servers running Windows NT 4.0 and earlier, read access for user and group information is assigned to anonymous users so that existing applications and some non-Microsoft applications function correctly.
On servers running Windows 2000 and Windows Server 2003, members of the Anonymous Logon group have read access to this information only when the group is added to the Pre-Windows 2000 Compatible Access group.
Using the Active Directory Installation Wizard, you can choose if you want the Anonymous Logon group and the Everyone security groups to be added to the Pre-Windows 2000 Compatible Access group by selecting the Permissions compatible with pre-Windows 2000 Server operating systems option. To prevent members of the Anonymous Logon group from gaining read access to user and group information, choose the Permissions compatible only with Windows Server 2003 operating systems option.
When upgrading a domain controller from Windows 2000 to a Windows Server 2003 operating system, if the Everyone security group is already a member of the pre-Windows 2000 Compatible Access security group (indicating backward compatibility settings), the Anonymous Logon security group will be added as a member of the pre-Windows 2000 Compatible Access security group during the upgrade.
You can manually switch between the backward compatible and high-security settings on Active Directory objects by adding the Anonymous Logon security group to the pre-Windows 2000 Compatible Access security group using Active Directory Users and Computers. For more information about adding members to a group, see Add a member to a group. For more information about default groups, see Default groups and Special identities.
Note
• If you select the Permissions compatible only with Windows Server 2003 operating systems check box when installing Active Directory and find that your applications are not functioning correctly, try resolving the problem by manually adding the special group Everyone to the Pre-Windows 2000 Compatible Access security group, and then restarting the domain controllers in the domain. Once you have upgraded to applications compatible with the Windows Server 2003 family, you should return to the more secure Windows Server 2003 operating system configuration by removing the Everyone group from the Pre-Windows 2000 Compatible Access security group and restarting the domain controllers in the affected domain.

 
Create an additional domain controller
Updated: January 21, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

To create an additional domain controller
1. Click Start, click Run, and then type dcpromo /adv to open the Active Directory Installation Wizard with the option to create an additional domain controller from restored backup files.
2. On the Operating System Compatibility page, read the information and then click Next.

If this is the first time you have installed Active Directory on a server running Windows Server 2003, click Compatibility Help for more information.
3. On the Domain Controller Type page, click Additional domain controller for an existing domain, and then click Next.
4. On the Copying Domain Information page, do one of the following:
• Click Over the network, and then click Next.
• Click From these restored backup files, and type the location of the restored backup files, or click Browse to locate the restored files, and then click Next.
5. On the Network Credentials page, type the user name, password, and user domain of the user account you want to use for this operation, and then click Next.

The user account must be a member of the Domain Admins group for the target domain.
6. On the Database and Log Folders page, type the location in which you want to install the database and log folders, or click Browse to choose a location, and then click Next.
7. On the Shared System Volume page, type the location in which you want to install the Sysvol folder, or click Browse to choose a location, and then click Next.
8. On the Directory Services Restore Mode Administrator Password page, type and confirm the password that you want to assign to the Administrator account for this server, and then click Next.

Use this password when starting the computer in Directory Services Restore Mode.
9. Review the Summary page, and then click Next to begin the installation.
10. Restart the computer.
Notes
• To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.
• The /adv switch is only necessary when you want to create a domain controller from restored backup files. It is not required when creating an additional domain controller over the network.
• In step 3, when choosing the option to copy domain information over the network, all directory data for the domain in which this domain controller will be a member will be copied over your network connection. You will have the option to cancel non-critical replication, if necessary.
• In step 3, when choosing the option to copy domain information from restored backup files, you will need to first back up the System State data of a domain controller running Windows Server 2003 from the domain in which this member server will become an additional domain controller. Then, the System State backup must be restored locally on the server on which you are installing Active Directory. To do this using Backup, choose the option Restore files to: Alternate location. For more information about restoring backups, see Related Topics.
• If a domain controller that was backed up contained an application directory partition, the application directory partition will not be restored on the new domain controller. For information about how to manually create an application directory partition on a new domain controller, see Related Topics.
• If the domain controller from which you restored the System State data was a global catalog, you will have the option to make this new domain controller a global catalog.
• You can also use a smart card to verify administrative credentials. For more information about smart cards, see Related Topics.
• You cannot install Active Directory on a computer running Windows Server 2003, Web Edition, but you can join the computer to an Active Directory domain as a member server. For more information about Windows Server 2003, Web Edition, see Related Topics.
Information about functional differences
• Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings. For more information, see Viewing Help on the Web.

Solution: I rebooted the computer several and got the same result each time.

I found the registry key entry that I used to fix the problem.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\PendingFileRenameOperations
Delete the registry key

Install the software without restarting the computer

NOTE: If you are running Windows Vista look for this key – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet001\Control\SessionManager\PendingFileRenameOperations

Answer was Posted on January 24th, 2009 under Symantec Endpoint Protection, Windows 2008 • Tags: Symantec Endpoint Protection, windows.

Solution:

1. Click on the “Round Office Bottom” (upper left side), Manage. Compaq and Repair Database.

2. Another solution is to add the “Compaq and Repair Database” to the “Quick Access Toolbar”: Next to Round Office Bottom” you will find other commands like “Save”, “Undo”… to the right there is a kind of down arrow – press on the arrow and click on more commands, now change the list of commands to show you “All Commands” scroll down to find “Compaq and Repair Database” and click on “Add” to add it to the Quick Access Toolbar.

I had a hard time finding this so I hope my notes will help you!

Cesar Lopez
Best Networks Inc

To obtain Cleanwipe please contact Symantec Technical support.
Once the utility has been obtained please follow these instructions:

This utility can be run on Windows 2000, Windows XP (32 and 64 bit), and Windows Server 2003 (32 and 64 bit.)

Warnings:
Do not run this utility on Windows NT, Windows 9x, or Windows Me.
Do not run this utility on systems that have Symantec AntiVirus 8.x or below installed.

You cannot select individual applications to remove.

CleanWipe may remove LiveUpdate.

CleanWipe will remove Virus Definitions if you select Yes to “Do you want to do a detailed MSI Product Code registry search?…”, even when selecting No to “If Virus Defs remain after uninstalling Symantec products do you want to uninstall the Virus Defs?”. If you have other Symantec applications that use the VirusDefs folder, it is recommended that you make backup copy of the VirusDefs folder before running the CleanWipe tool. The VirusDefs folder is located under C:\Program Files\Common Files\Symantec Shared\

When using the CleanWipe utility, please be aware that it removes the following products and components from the computer:

Alert Management Server
Firewall Administrator
Quarantine Console
Quarantine Server
Symantec AntiVirus (Version 9.x and above)
Symantec AntiVirus Corporate Edition
Symantec Client
Symantec Client Firewall
Symantec Client Security
Symantec Endpoint Protection
Symantec Endpoint Protection Manager
Symantec LiveUpdate
Symantec Network Access Control
Symantec Sygate Enterprise Protection
Symantec System Center
Symevent

If you have other Symantec applications on the computer that depend on any of the applications listed above, those applications may not function properly. The customer may need to re-install the missing applications after running CleanWipe.

Note: The zip file is password protected.
Un-Zip Password: symantec

1. Extract the file to a new folder in a convenient location, such as the Desktop, using the un-zip password provided above.
2. Browse to the new folder and execute the utility by double clicking ‘CleanWipe.exe’
3. Follow the on-screen instructions.

The utility runs in verbose mode and will ask you about the components you want uninstalled.

Note: If the CleanWipe utility fails to remove Symantec Endpoint Protection, please proceed through the manual uninstall procedure for the version of the product you have installed.

You can find the manual uninstall instructions in the following document:

Title: How to manually uninstall Symantec Endpoint Protection client from Windows 2000, XP and 2003, 32-bit Editions
Solution ID: 2007073018014248
Document URL:

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007073018014248

Title: ‘Manual uninstallation documents for Symantec Client Security products’
Solution ID: 2002031914291648
Document URL: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2002031914291648

————————————————[UPDATE]——————————————————–
You can use CLEANWIPE from Symantec to remove the AV and all other associated applications.

To download the utility, open the following web page in a browser:

https://fileshare.symantec.com

Log in with the following information:

Login ID: cleanwipeutility
Password: CL3@nw!p3

Once you have downloaded the utility, please follow these instructions.

Note: The zip file is password protected.
Un-Zip Password: symantec

1. Extract the file to a new folder in a convenient location, such as the Desktop, using the un-zip password provided above.
2. Browse to the new folder and execute the utility by double clicking ‘CleanWipe.exe’
3. Follow the on-screen instructions.

The utility runs in verbose mode and will ask you about the components you want uninstalled.

Note: If the CleanWipe utility fails to remove Symantec Endpoint Protection, please proceed through the manual uninstall procedure for the version of the product you have installed.

You can find the manual uninstall instructions in the following document:

Title: How to manually uninstall Symantec Endpoint Protection client from Windows 2000, XP and 2003, 32-bit Editions
Solution ID: 2007073018014248
Document URL:

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007073018014248

Title: ‘Manual uninstallation documents for Symantec Client Security products’
Solution ID: 2002031914291648
Document URL: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2002031914291648

Some of you out there perhaps are having time synching problems – May of my clients did – here are some notes that can help you fix the problem.  Warning, these changes could prevent workstations from being able to log back into the server – please read carefully, if you have any questions please call us.

The problem:  The Primary Domain Controller PDC/ Server is off by minutes from the actual time.   Workstations synch with the PDC Server and perhaps users use applications that require the correct time – Time-sheets, etc.

Traditionally, the LAN Administrator would log onto the server and correct the time manually.  The server would be fine for few months and eventually someone would alert the LAN Administrator the time is off again. 

This is an issue with old servers that rely on their internal time clock.  The internal time clock is powered by a battery just like you watch and once this battery no longer recharges then the time it constantly needs to be set manually – as part of the solution – You could also change the internal CMOS battery.  However, nowadays almost everyone has access to the internet and there are other solutions to this problem.   One solution is presented here – I use this solution internally in our Network and it works great.

The traditional method to synch the workstation clock with the server also needs to be recognized as part of the problem as this is a manual command that needs to be automated.

This command allows the workstation to synch its time against the file server.  I have implemented this command as part of the logon script many times.  I would like to find a better solution. Perhaps – Visual basic scripting or as part of a Group/Domain Policy.

[Microsoft Article ]

Synching to an Internal Time Source

The simplest solution to time synchronization in an Active Directory environment is to let the PDC Emulator in the forest root domain use its own CMOS clock as the source of reliable time for the forest. To do this, you can simply take no action. The only annoying result is that you will occasionally see the following event logged to the System log in Event Viewer:

Event ID: 12

Event source: W32Time

Event description: Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient.

Basically, what this event means is that the PDC Emulator in the forest root domain has not been configured to synchronize its clock with an external stratum 1 time source, and as a result the clocks on all machines in your forest cannot be considered reliable. Now this may be an issue if employees rely upon their workstations’ CMOS clocks for signing in and out, but as far as Kerberos is concerned it’s a non-issue because Kerberos only requires that clocks on clients and authenticators agree with each other, not that they display accurate time. So if every machine’s clock in the forest is one hour late, Kerberos will still work fine and replay attacks will be prevented, which is the purpose of W32Time anyway.

Synching to an External Time Source

If you want to ensure that the clocks on your machines are more accurate in terms of absolute (and not just relative) time, you can sync the PDC Emulator in your forest root domain to one of the reliable time servers available on the Internet. This is a good idea if your company is a large enterprise with sites spanning several countries, or if your organization has two or more forests linked by forest trusts. The procedure for doing this on a PDC Emulator running Windows Server 2003 in the forest root domain is as follows. Open Registry Editor (regedit.exe) and configure the following registry entries:

1   HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type

This registry entry determines which peers W32Time will accept synchronization from. Change this REG_SZ value from NT5DS to NTP so the PDC Emulator synchronizes from the list of reliable time servers specified in the NtpServer registry entry described below.

2   HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags

This registry entry controls whether the local computer is marked as a reliable time server (which is only possible if the previous registry entry is set to NTP as described above). Change this REG_DWORD value from 10 to 5 here.

3   HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer

This registry entry specifies a space-delimited list of stratum 1 time servers from which the local computer can obtain reliable time stamps. The list may consist of one or more DNS names or IP addresses (if DNS names are used then you must append ,0×1 to the end of each DNS name). For example, to synchronize the PDC Emulator in your forest root domain with tock.usno.navy.mil, an open-access SNTP time server run by the United States Naval Observatory, change the value of the NtpServer registry entry from time.windows.com,0×1 to tock.usno.navy.mil,0×1 here. Alternatively, you can specify the IP address of this time server, which is 192.5.41.209 instead.

• NOTE:  I’m not sure but…  if I’m working on a workstation (say windows XP-PRO or Vista) will it work if I change the name of the external server to the name of the Internal Domain controller Server? After all,  the PDC is already synchronizing against the external server per the steps above.  I will test this on a vista computer and later on an XP computer!!!  The problem I have with this is that this is a manual change and I will like it best to be an automated change – specially if I have to do it on a client site with 100s of computers.  Alternatively I would use the net time \\server /set < [mapped-drive path]\yes.txt comand.

Now stop and restart the Windows Time service using the following commands:

4    net stop w32time  && net start w32time

It may take an hour or so for the PDC Emulator to fully synchronize with the external time server because of the nature of the polling method W32Time uses. Depending on the latency of your Internet connection, the accuracy of the CMOS clock on your forest root PDC Emulator may be within a second or two of UTC. If you need more accurate time however, you can purchase a hardware time source like an atomic clock and connect it to your PDC emulator.

Alternatively, if you don’t want to wait for time convergence to occur between your stratum 2 time server (your forest root PDC Emulator) and the external stratum 1 time server, you can run the following command on your PDC Emulator:

5    w32tm /resync /rediscover

Tip
There are additional registry settings you can configure to ensure external time synchronization operates effectively, see this article in the Microsoft Knowledge Base for details.

All available synchronization mechanisms

The “all available synchronization mechanisms” option is the most valuable synchronization method for users who are on a network. This method enables synchronization with the domain hierarchy and may also provide an alternative time source if the domain hierarchy becomes unavailable, depending on the configuration. If the client cannot synchronize time with the domain hierarchy, the time source automatically falls back to the time source that is specified by the NtpServer setting. This method of synchronization is most likely to provide accurate time to clients.

Windows Time service registry entries

The following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\

Collapse this tableExpand this table

Other links:

http://www.windowsnetworking.com/articles_tutorials/Configuring-Windows-Time-Service.html?printversion

[Sony Letter]

Sony Electronics Inc.

1 Sony Drive, Park Ridge, New Jersey 07656

October 2009

Dear Valued Sony AIT Tape Drive Customer:

This letter serves as a soft reminder to our channel partners that, as of March 2010, Sony Electronics Inc. will no longer be offering AIT drives or AIT library/automation systems. This difficult decision was made after careful review and consideration.

As stated in our previous letter issued in April 2009, Sony will continue to accept purchase orders for delivery through March 2010 subject to product availability, however, due to stronger than expected sales demand, we are already running out of inventory on some product lines, specifically AIT-2T, AIT-3 and AIT-5 tape drives.

As a result of this, we are compelled to inform you of the models which are still available for sales as of this date, as shown below;

Easier Maintenance of Sony AIT-3 WORM Tape