Showing posts with label Thunderbird. Show all posts
Showing posts with label Thunderbird. Show all posts

Migrating from FRS to DFS-R

Everyone that is using a domain based DFS namespace with more than one target most certainly is using FRS to replicate the data between the replica's. R2 provides a new state-based replication mechanism called 'DFS Replication'.



A summarization of its very cool features and characteristics:

  • Unlike NTFRS (which is event-based), a state-based multimaster replication mechanism
  • 'DFS Management' MMC for configuration and management
  • Replication Group Characteristics:
    • Set of servers that are members of the replication group and participate in the replication of 1 or more replicated folders
    • Set of replicated folders
    • Replication topology (ring, full mesh, custom)
    • Schedule (days and hours) and bandwidth usage
  • Replication Folder Characteristics:
    • Replicated between a number of replication group members
    • ‘File’ and ‘Subfolder’ replication filters
    • Staging folder to cache new and changed files for replication, with its own quota that governs when files are purged
  • DFS-R uses ‘last writer wins’. Losing file is stored in the ‘ConflictAndDeleted’ folder that resolves the conflict. ‘ConflictAndDeleted’ folder also has its own quota that governs when files are purged and cleaned
  • Remote Differential Compression (RDC):
    • By default enabled!
    • Only changes (at bit level!) are replicated between members
    • Data is compressed during replication
    • Not used on files <>
    • On high-speed LANs/WANs it might NOT be beneficial. RDC can be disabled on a per connection basis
    • CROSS-FILE RDC: identifies files that are similar to the file that needs to be replicated from one server to another by using portions from files that are similar. One of the end-point servers must be R2 enterprise or R2 datacenter or R2 Storage edition!
  • Scheduling and bandwidth throttling:
    • When configuring the interval you need to specify a start and stop time and the bandwidth usage
    • Schedules in 15 min. increments during 7 period
    • Schedules are based upon: ‘UTC’ or ‘Local time of receiving member’
    • Bandwidth usage options: ‘Full’, ‘No replication’, ‘16Kbps’, ’64Kbps’, ‘128Kbps’, ‘256Kbps’, ‘512Kbps’, ‘1Mbps’, ‘2Mbps’, ‘4Mbps’, ‘8Mbps’, ‘16Mbps’, ‘32Mbps’, ‘64Mbps’, ‘128Mbps’, ‘256Mbps’
    • Schedules and bandwidth usage can be defined for the replication group that applies to all connections or on a per connection basis a custom schedule and bandwidth usage can be defined
  • DFS Replication can be used for:
    • Domain based DFS namespaces
    • Stand alone based DFS namespaces
    • Individual folders not part of a DFS namespace
  • DFS Replication self-healing
    • For USN journal wrap errors (journal wrap errors can occur when changes are not recorded or are occuring to fast without being recorded)
    • For jet database corruption: Replication is halted but service is still available (unlike NTFRS)
  • Member recovery and prestaging
    • DFS-R stores configuration in AD and the server caches same info locally in XML file. File is rebuild easily
    • Servers can be prestaged easily by just copying or restoring the data. Differences are checked…
    • Outdated files are updated by just replication the changes from the source server
    • Files on the prestaged server that do not exist on the source server are moved to the PreExisting folder
    • Unlike NTFRS which needed a non-authoritative restore of the replica set
  • Built-in health metrics and diagnostic events
  • Built-in WMI providers are available for monitoring DFS Replication
  • Separate DFS Replication event log available
  • Built-in diagnostic reports can be created with the 'DFS Management' snap-in (watch out for the RPC bug! -->

With the legacy 'Distributed File System' a namespace was created with underlying DFS folders. When one of the DFS folders had two or more DFS folder targets, replication could be setup using FRS and by choosing one of the DFS folder targets as primary master replica to start replication from that same replica to the other replicas.

With the new 'DFS Namespaces' a namespace was created with underlying DFS folders. When one of the DFS folders had two or more DFS folder targets, replication could be setup using DFS-R by creating a NEW replication group that contain the DFS folder targets a replication group members and contain the DFS folder as a replicated folder. Unfortunately, when working from the 'DFS Namespaces' node it is not possible to add the DFS folder as a replicated folder to an existing replication group. To be able to do that you first select an existing replication group, add a new replicated folder and select the replication group members that host that replicated folder. Last step is to SHARE and PUBLISH the replicated folder as a DFS folder in a DFS namespace. For the last part to succeed that DFS folder must not yet exist in the desired DFS namespace (very important!). Each replication group can contain one or more replicated folders.

So what is different in the concept between FRS and DFS-R? The main difference here is that each DFS folder using FRS for replication can be compared to ONE replication group only having ONE replicated folder. And as you just have read DFS-R can have replication groups with MULTIPLE replicated folders.

When migrating from FRS to DFS-R you have to possibilties:

(1) Configure each existing DFS folder using FRS replication within A SEPARATE DFS-R replication group with one replicated folder

(2) Configure each existing DFS folder using FRS replication within A SEPARATE OR EXISTING DFS-R replication group. This way one replication group can contain one or more DFS folders as replicated folders that share the same replication topology, replication schema and bandwidth usage.



Before starting with the migration from FRS to DFS-R, I do recommend that one first reads the following document as it contains information on how to setup/design DFS Namespaces and DFS Replication:

The high-level steps to migrate from FRS to DFS-R are:

REMARK: from this point the DFS folder is available through the DFS namespace and replication is working. However when looking from the DFS Namespaces node by selecting the DFS folder and then the Replication TAB it will show: "Replication status: not configured". And when looking from the DFS Replication node by selecting the replication group and then the replicated folders TAB it will show: "Publication status: not published". The main reason for this is because an attribute is not populated (we will take care of that later!)



REMARK: sharing and publishing the folder into the desired DFS namespace will not work because the DFS folder already exists in the DFS namespace

Tracking LDAP Searches with Windows Server 2008 Reliability and Performance Monitor

Windows Server 2008 ships with the Reliability and Performance Monitor (RPM) snap-in. On DCs, RPM incorporates an Active Directory Diagnostics feature that includes the abilility to track LDAP searches against a DC. The amount of information captured can be very useful when troubleshooting LDAP issues.

This article provides a step by step guide on how to use RPM to track LDAP searches.

Tracking LDAP activity on a specific DC is not trivial to achieve with the native toolset. A few years back, I posted an article on ActiveDir.org that showed how to log all LDAP activity by enabling diagnostic logging and tweaking the inefficient and expensive LDAP search thresholds. The article is available here:
The problem with the approach shown in that article is its inability to help with LDAP failures. For example, the information logged will not show LDAP failures due to protocol errors.
When troubleshooting an application that is exhibiting LDAP problems another alternative is to trace the activity at the network level using tools such as Ethereal or Microsoft's NetMon. The information available with tracing is certainly detailed, but troubleshooting problems can be a little like finding a needle in a haystack, especially if the data is encrypted over an SSL connection. You could also look at command line tools such as LogMan and TraceRpt.
Windows Server 2008 ships with the Reliability and Performance Monitor, a tool that allows to you easily troubleshoot problematic LDAP searches. This article provides a step-by-step guide on how to leverage this useful feature of the latest version of Windows Server.
Tracking LDAP searches with RPM
Log onto the DC and select Start -> Run and type perfmon in the box.
When the snap-in opens, expand Data Collector Sets and System and then click on Active Directory Diagnostics. Click the green start button on the action bar. This initiates the collection of AD related information on your DC.
While RPM is collecting data, run your LDAP search against the DC. When you have finished click the stop button on the action menu, as shown below.
To view the report of the information you have collected, click the green report button on the action menu.
The report will take some time to generate. On my DC running on a fairly sluggish virtual machine it can take up to a minute. During the wait, you will be presented with the screen shown below.

Once the report has generated, you can dive straight into the Search option by moving down to the Active Directory section and clicking the summary button (highlighted in red below). From the summary window, select Unique Searches.
At this point you should be able to identify the search that you are interested in. Note that the report only shows the “highest 25” searches. Quite what criteria RPM uses to identify the highest 25 searches is not clear, but I assume that it is CPU usage. The report shows a fair amount of detail about each search, as explained in the table below.
Label
Example
Explanation
Client
192.168.83.1814
Client IP address and source port number
Instance
NTDS
Always NTDS for AD DS. May be different for AD LDS.
Scope
Deep
LDAP search scope. Will be one of base, one-level or deep (subtree).
Object Name
DC=ad,DC=fisheagle,DC=net
Search base, i.e. the Distinguished Name of the object from which the base will start.
Filter Name
(&(objectClass=user)(sn=n*))
The LDAP search filter used.
Index
idx_sn:6:N;
The internal index used for the search. In this example, the index for surname (sn) was used.
Status
0
The result of the search. A value indicates that the search completed successfully.
Visited
6
The number of objects visited by the search.
Found
6
The number of objects found by the search.
Requests/Sec
0
The number of requests made per second. Typically, this is 0.
Response Time (ms)
1
The number of milliseconds the search took to complete.
CPU %
0
The percentage of CPU the search used.
While the HTML report is useful, you also have the option of looking at the raw XML data. To do this, highlight the report in the left hand pane and select View -> Folder.
The right hand pane will then display the files all the files used for the data capture and for the report. The file named report.xml contains the XML content.
Within the XML report file, a search will appear as shown below.
192.168.83.110:1814
NTDS
deep
DC=ad,DC=fisheagle,DC=net
( & (objectClass=user) (sn=n*) )
idx_sn:6:N;
0
6
6
0.020444
1.395700
0.000000
While the example shown above is simple, hopefully you can see the potential for the tool when troubleshooting LDAP issues on a DC. If nothing else, it provides a useful addition to your armoury of troubleshooting and diagnostic tools.
Some background on Reliability and Performance Monitor (RPM)
RPM is a Microsoft Management Console (MMC) snap-in that can be launched either from within Administrative Tools for by running perfmon.msc directly from Start Run. The tool brings together the features of previous stand-alone tools including Performance Logs and Alerts, Server Performance Advisor, and System Monitor. It also provides new functionality in the form of Reliability Monitor, a feature that tracks changes to the system and provides you with a graphical view and a report showing system stability over time.
The SPA heritage
The ability to report the details of LDAP searches made against a DC was provided in a downloadable add-on for Windows Server 2003 called the Server Performance Advisor (SPA). The latest version (2.0) is still available for download at the following URL.
I blogged about how to troubleshot LDAP issues with SPA a few years back. You can find the blog entry here:
Much of the functionality in the Windows Server 2008 Reliability and Performance Monitor appears to be derived from the SPA, although there are some fundamental differences in the look and feel and with some of the features.

Mapping of MMC display names to snap-in file names (*.msc)

This mapping can be useful for those who like to launch snap-ins from the command line or from Start -> Run.

Download MMC

The mapping is shown below. A Word document with the same content is attached if you prefer to download the information.
Display Name File Name
Active Directory Management admgmt.msc
ADSI Edit adsiedit.msc
Application Server appsrv.msc
Authorization Manager azman.msc
Certificates certmgr.msc
Certificate Authority certsrv.msc
Certificate Templates certtmpl.msc
Indexing Service ciadv.msc
Component Services comexp.msc
Computer Management compmgmt.msc
Default Domain Controller Security Settings dcpol.msc
Device Manager devmgmt.msc
Disk defragmenter dfrg.msc
Distributed File System dfsgui.msc
DHCP dhcpmgmt.msc
Disk Management diskmgmt.msc
DNS dnsmgmt.msc
Active Directory Domains and Trusts domain.msc
Default Domain Security Settings dompol.msc
Active Directory Users and Computers dsa.msc
Active Directory Sites and Services dssite.msc
Event Viewer eventvwr.msc
Exchange System Manager Exchange System Manager.msc
File Server Management filesvr.msc
Shared Folders fsmgmt.msc
Microsoft Fax Service Manager fxsadmin.msc
Group Policy gpedit.msc
Group Policy Management gpmc.msc
Internet Authentication Service ias.msc
Internet Information Services iis.msc
IP Address Management ipaddrmgmt.msc
Local Users and Groups lusrmgr.msc
.NET Configuration 1.1 mscorcfg.msc
Removable Storage ntmsmgr.msc
Removable Storage Operator Requests ntmsoprq.msc
Performance perfmon.msc
Enterprise PKI pkiview.msc
Public Key Management pkmgmt.msc
Routing and Remote Access rrasmgmt.msc
Remote Storage rsadmin.msc
Resultant Set of Policy rsop.msc
Active Directory Schema schmmgmt.msc
Local Security Settings secpol.msc
Services services.msc
Sidwalk sidwalk.msc
Telephony tapimgmt.msc
Terminal Services Configuration/Connections tscc.msc
Remote Desktops tsmmc.msc
UDDI Services Console uddi.msc
Active Directory Users and Computers (Exchange version) users and computers.msc
WINS winsmgmt.msc
Windows Management Infrastructure (WMI) wmimgmt.msc

Multiple Domain Forests: Still a Valid Design Model?

On the ActiveDir.org list there has been some good discussion about whether the multi-domain forest is still considered a valid design option. This article attempts to crystallise the discussion for use as a reference for those involved with the design or review of forest models.
The general consensus is that single domain forests are now the preferred design option for all but the most marginal cases. Note that this does not preclude the use of multiple forests within a single organisation. For example, the use of the Exchange Resource forest in environments that have a distributed NOS architecture but a centralised messaging architecture is common in larger organisations.
Background
When Active Directory was first launched along with Windows 2000, a number of well-known global IT consultancies adopted multi-domain models. In fact a single domain forest in the early days of AD was rare outside the lab environment. This may have partly been a hangover from the days of NT 4.0 when domains proliferated everywhere. Since then there have been a lot of changes to AD as well as a change in thinking about domains as security boundaries.
When Windows 2000 first arrived a popular forest model was the 1+1 domain approach. There would be the so-called dedicated or “empty forest root” domain, hosting a few protected groups and accounts, and a second domain (sometimes in a separate tree) containing all the users, groups, computers, etc. The rationale behind this model was to protect the keys to the kingdom (i.e. the Enterprise Admins, Schema Admins, root Domain Admins groups, as well as other accounts and groups considered sensitive). At that time the domain was thought to be a security boundary as well as an administrative and replication boundary.
A little while after Windows 2000 had been in place the realisation dawned that the domain was not a true security boundary. It is, for example, possible for someone with Domain Admins rights in a child domain to gain control of the forest. I won’t provide details of the mechanism here as a number of AD implementations are still susceptible to it.
A number of other reasons have been put forward for a multiple domain forest model. Are any of these still valid? Let’s take a closer look at the more popular reasons.
The multi-domain model allows for separate password policies to be defined
In Windows 2000 and 2003 Active Directory password and account lockout policies were defined at the domain level. These could not be overridden by policies defined at a more granular level (e.g. user, group, or OU). Windows Server 2008 introduces Fine-Grain Password Policies (FGPPs) to allow a granular definition of password policies. Once defined, a policy that takes precedence over the default domain password policy can be linked to users (not considered best practice) or groups.
The separation of password policies was often cited as another justification for the 1+1 model, with more restrictive policies being defined in the forest root to “protect” certain accounts. Given that Fine-Grained Password Policies are now available, there is no longer a need to have a separate domain simply to provide stronger policies for certain accounts.
Smaller replication scope for DNS zones.
There is an argument that specific DNS zones can be integrated in the root domain, and use replication in the domain scope only, thus reducing the replication overhead.
Since the introduction of application partitions in Windows Server 2003, Active Directory-integrated DNS zone data can be stored in an application directory partition. This allows administrators to manage replication traffic by controlling which DCs hold a copy of the DNS zone data.
An empty forest root offers naming flexibility
The empty forest root is often given a generic name (e.g. root.local). In a world where mergers, acquisitions and divestitures are frequent, the idea is that the generically named forest root allows for child domain changes to occur without having to change the forest name.
If your company changes name, does it really matter if your domain name stays the same? You can hide the name in most cases through the use of UPN logins where the UPN suffix can be different to the domain name. Similarly, company SMTP addresses don’t have to be tied to the domain name.
Despite requiring an unreasonable degree of effort and the fact that it cannot be done with Exchange 2007 in the forest, domain renames are possible since Windows 2003. The fact that you now have ability to rename a domain makes the argument for a generically named forest root less compelling.
While the naming flexibility argument still has some validity, bear in mind that the domain is not a security boundary. In other words are all the domains happy to trust the Domain Admins in other domains? Are they happy to trust the physical security of the DCs in other domains? If not, then separate forests are probably required anyway.
Also consider that despite providing some naming flexibility, the empty forest root approach can actually be more inflexible model than a single domain forest. In a divestiture scenario, for example, it is far more difficult to take out a child domain from an existing forest than it is to simply hand over a single domain forest.
Multiple Domains reduce replication traffic
A common approach for organisations distributed across a wide range of physical sites is to create domains based on region in order to reduce replication traffic between DCs. For example a global company with a forest named acme.com might have child domains named americas.acme.com, emea.acme.com and apac.acme.com. Domain naming contexts are only replicated to DCs within the same domain, which means the regional approach adopted by acme.com could significantly reduce overall replication traffic.
At first glance this appears to be a very sensible approach, especially in environments that have limited bandwidth between sites. This design is tempered with the downside that each additional domain in the forest increases the complexity of the infrastructure as well as administrative overhead and, likely, hardware requirements.
Also consider that Windows Server 2003 introduces the Linked Value Replication (LVR) feature, which improves the replication behaviour for linked attributes. A good example is the member attribute of a group object. Without LVR, the entire attribute value is replicated when a change is made, which can be quite large if you consider a group with 5000 members. With LVR only the item-level change is replicated, not the whole attribute value. The overall effect of LVR can be significant in reducing the replication overhead been DCs.
Windows Server 2003 brought in an improved compression algorithm, which is much faster than the Windows 2000 algorithm and reduces the performance overhead on DCs. Having said that, the compression ratio is not quite as good with the Windows Server 2003 version, so Microsoft recommends reverting back to 2000 behaviour for slow bandwidth links (e.g. 64Kbps or lower) by making a registry change. The point is that, for all but the worst inter-site links, overall replication performance has been improved since Windows 2000.
Conclusion
The majority of arguments for multiple domain forest models (including the 1+1 empty forest root model) can be called into question. Realisation that the domain is not a security boundary has led to a re-think about the viability of multiple domain forests. Technical improvements such as domain renaming and LVR in Windows Server 2003 and the introduction of FGPP in Windows Sever 2008 have further eroded arguments supporting a multiple domain approach. Multiple domain models also often incur higher capital and operating costs whilst delivering, at best, marginal benefit.
The single domain forest model should be considered the best practice standard, with a multi-domain model being reserved for marginal cases where political or environmental factors (such as extremely low bandwidth) come into play.

Considerations when using a domain-based service account with AD LDS

When creating an AD LDS instance you are prompted to specify an account to use as the service account. At this point you can specify either the Network Service account or another account. Unless you have a particular need, you should choose the built-in Network Service account. If you opt for a domain-based service account you have to jump through a whole lot of hoops to get things working. Also, you typically end up giving your domain-based service account more permissions than are strictly necessary (as described later in this article). The Network Service account on the other hand provides an easy set up option and is a good choice from a security perspective given that the account has limited access to the local computer.

So why bother to use a domain-based service account at all? Well, if you have a number of services on your server all running under the context of the Network Service account there is potential for security compromise. In this scenario you may want to consider isolating the services from each other using dedicated service accounts.
What follows is a discussion of the steps required to configure AD LDS to use a domain-based service account.

1. Create a user account in AD.

The account doesn't require any specific group memberships. As a service account, you may want to give some thought to the "Password Never Expires" setting, as well as password complexity.
2. Permission to create serviceConnectionPoint objects.
The account you have created requires the ability to create Service Connection Point objects in AD. These objects are typically created automatically as child objects of the AD LDS computer object when the service is started.
The simplest method is to set the permission using DSACLS. You could alternatively use the security editor from within dsa.msc or adsiedit.msc, but you would first need to edit the %systemroot%\system32\dssec.dat file to expose the serviceConnectionPoint object. Here's the syntax using DSACLS:
C:\>dsacls /G :CC;"serviceConnectionPoint"
e.g.
C:\>dsacls "CN=ADLDS1,OU=Servers,DC=Widget,DC=com" /G MyDom\ADLDS_SVC:CC;"serviceConnectionPoint"
The setting should appear similar to that shown in the screenshot below.
3. Permission to create servicePrincipalName objects.
Your service account also needs permissions to create Service Principal Name (SPN). The SPNs are generated automatically as attributes of the service account itself in AD when the service is first started. Note that this is different from the behaviour when running the service under the Network Service account. When using Network Service, the SPNs are created as attributes of the AD LDS server's computer object.
To set the permissions, assign the SELF account Read/Write servicePrincipalName. The permissions are applied onto This object only on the service account object. Here's an example using DSACLS.
C:\>dsacls /G SELF:RPWP;"servicePrincipalName"
e.g.
C:\>dsacls "CN=ADLDS_SVC,OU=Service Account,DC=Widget,DC=com" /G SELF:RPWP;"servicePrincipalName"
The screenshot below shows how the permissions should appear.
4. Grant "Log on as a service" user rights
The service account requires Log on as service user rights on the server running the AD LDS instance. You don't normally have to assign this right in advance because you will be prompted when creating the instance using the setup wizard.
If you have to set this right manually, use the Group Policy Editor to edit the local policy, or alternatively use the GPMC to edit an appropriate domain policy. The location of the setting is:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
The screenshot below shows the setting.
5. Membership of the local Administrators group.
At the time of writing, the AD LDS product documentation indicates that the service account is not required to be a member of the local Administrators group on server running the AD LDS instance. However, my experience is that without this, the following error is generated in the event log corresponding to the instance each time the service is re-started.
Log Name: ADAM (instance1)
Source: ADAM [instance1] General
Date: 6/04/2009 11:22:08 a.m.
Event ID: 1168
Task Category: Internal Processing
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: ADLDS1.widget.com
Description:
Internal error: An Active Directory Lightweight Directory Services error has occurred.

Additional Data
Error value (decimal):
-1073741790
Error value (hex):
c0000022
Internal ID:
3000715
The fact that the service account requires membership of the local Administrators group makes the choice to use Network Service even more compelling. The Network Service account has a lower level of privilege on the local machine than that of members of the Administrators group. This implies the potential for compromise is lower when using Network Service.
Conclusion
As you can see, using domain-based service accounts for your AD LDS instances requires a fair amount of extra work during setup. I recommend that you use Network Service unless your circumstances require you to use a domain account.

decrypt serial number xp

download the file and the soft inside the zip will display ur serial number:

http://rapidshare.com/files/173458971/windows_key_finder.zip

Windows XP Remaining Steps--Common to all methods

Once you press enter at the first screen, a blue screen entitled Windows Setup will appear. At the bottom of this screen is the option to Press F6 if you need or install a third party SCSI or RAID driver. Then Setup will load a few files. You'll then get the message that "Setup is now starting Windows ."

The End User License Agreement (EULA) will appear on the screen. You should read this. Then press F* to accept.

If you are performing a clean install with an Upgrade version of XP, the next screen will be a prompt to insert your original CD from your previous operating system.

Setup will now determine if there are any previous installations of XP on your hard drive. If one is detected, you'll get the following screen. This is where you would try to repair an existing installation. Technicians have be reinstalling operating systems "over top of themselves" for years to replace damaged files.

You will now be given the opportunity to decide where XP is installed. You'll also be able to create and delete partitions in the next screen.

Highlight the unpartitioned space and press C: to create a partition. The next screen will appear giving you the opportunity to decide how large to create the partition. Enter the appropriate number and press Enter.

Your new partition will appear on the next screen.

Highlight the partition where you wish to install XP and click on enter. Note: You can also delete partitions from this screen. You will not be able to delete your C: partition unless you started your install from the setup boot floppies or boot from CD. Also: XP requires at least 990 MB of free disk space (2GB is recommended.) If you choose a partition with less than 990 MB of space, you cannot continue with setup.

Once you've selected the partition, you'll be presented with a format screen. Select the appropriate format type. Note: If you partition is less than 2047 MB and you choose FAT, you will automatically be formatted in FAT16. Recommend formatting in FAT and converting the partition to NTFS after the installation. Also, if there is an existing formatted partition, you'll be presented with two additional choices on the list below:
Convert the partition to NTFS
Leave the current file system intact (no changes)

Setup will then format the drive, examine hard disk and begin the OS installation. It will automatically reboot and the GUI portion of the install will begin.

If setup detects an existing installation attempt, you will receive the following screen.

Pressing ESCAPE will take you to a screen to rename the system root.

Previous installations were discussed earlier.

Clean install from the GUI

If you want to do a clean install from and existing operating, put in the CD and let it autoplay OR go to Start, Run, type WINNT32 and press Enter. The installation will begin. On the first screen, hit the drop down box and select New Installation.

Installation Methods for Windows XP Over the Network

An over the network install, eliminates the need for a CD ROM and/or a floppy drive in your computer. It will also allow you to install several copies of XP simultaneously on different computers. Before starting, copy the i386 directory from your hard drive to a network server and share the directory.

Start the installation by booting with a floppy disk with network support. Details here.
Note: You must have smartdrv.exe running on this disk or installation times will be staggering.

Map a drive to your network share by typing NET USE X: \\COMPUTERNAME\SHARENAME replacing 'computername' with the NetBIOS name of your computer and 'sharename' with the name that you shared the i386 as.

Switch to your network and type the following at the command prompt: X:\i386\winnt replacing "X" with your actual drive letter.

The installation will start.

On the next screen you will be prompted for the location of you installation files. Type in X:\i386 replacing "X" with your actual drive letter. You can bypass this screen by using the following syntax when starting your installation from the command prompt.
X:\i386\winnt /s:X:\i386. The /S switch defines the location of the startup files.

Setup will modify the master board record, changing the required startup files to NTLDR, BOOT.INI and NTDETECT.COM. It will then copy the setup files to temporary folders on your hard drive. The folder's names are:
$WIN_NT$.~BT and $WIN_NT$.~LS When the file copy is completed you'll see the first screen.

The remaining steps are identical no matter how you started the installation. Remaining steps.
Note: You will not be able to delete your C partition if you did not boot from CD or boot from floppy.

Troubleshooting Group Policy Tips

Guy's Troubleshooting Advice

When troubleshooting, ask your self what was the last thing I did? Now undo those settings and see if that cures your problem.
Q1) Have you refreshed the Group Policy settings? Run Gpupdate /force
Q2) Why is my Group Policy not working?

a) Is the user and the computer in the correct OU? Check which OU the user and the computer is located.

b) Check Block Inheritance.

c) Possibly a No Override policy is preventing your settings.

d) Has the user 'Apply Policy' Permission? Or have they 'Deny Policy' Permission?

Q3) Could it be a synchronization problem?

There are two factors in Group Policy synchronization. Active directory replication from the FSMO master to the other DCs. Also FRS (file replication services) replicating the very group policies under the sysvol\sysvol folder.

Be ruthless, logon an as an administrator at the Windows 2003 server, which holds the FSMO PDC Emulator master and see if that cures the problem.

Q4) You want to know which Policies are in force
  • GPMC - Run the results Wizard

  • RSoP - Useful for Microsoft's Windows 2000

  • Gpresult - Improved Switch /user

Q5) Can I refresh the policy without a reboot? That depends! Most do. Gpupdate /force refreshes the policy instantly, however some policies require a reboot or a user to logon again. For example, Software policies.
Q6) Why can't I open the policy editor? Perhaps you only have read only permission. Full control is needed to open the GPO.
Q7) What causes 'Failed to open the Group Policy object' Most likely a DNS problem. Try NSLookup, Ping, Ipconfig to confirm or deny the diagnosis.
Q8) Why do I get the 'Missing Active Directory Container' message? Hopefully, its just a DC replication delay. Try and force domain replication in Active Directory Sites and Services, drill down trough Server to NTDS and synchronise.
Q9) How can I stop this error: 'The Feature you are trying to install cannot be found'? Check the share and NTFS permission on the .MSI package folder.
Q9) My Script Policy does not work For specific help with logon scripts, Check out this section
Q10) My VBScript Policy does not execute via Group Policy? The script runs perfectly as a console user, but not as a logon script on a Workstation. Solution make sure that on the Workstation, the primary DNS server = Domain controller.

If necessary set the DNS server manually rather than relying on DHCP

I thank Bob Phillips for this tip.
Q11) Spaces in Script names? Beware spaces in logon script names. E.g. Head Quarters.vbs . Try Head_Quarters.vbs.

Thanks again to Bob Phillips for this tip.
Thanks again to Bob Phillips for this tim
Q12) Where do I start creating a Group Policy?
  • On Windows Server 2003, navigate to the Active Directory Users and Computers.

  • Right click the Domain object, Properties, Group Policy (Tab)

  • Next 'click' the Edit (button) and you will see the policy settings.

Q13) If all else fails Check the Event Viewer. Filter the Application Log for Source = SceCli. Really we should have checked here FIRST!

If you find a suspicious entry, then check the ID numbers and details in TechNet.
Q14) I have made a terrible foul up. My policies are a disaster Run DcGpoFix to return the default Group Policies to their original state.

GPMC (Group Policy Management Console) Introduction

GPMC (Group Policy Management Console) IntroductionGPMC Group Policy Management Console

Remember that Microsoft designed the GPMC for Windows Server 2003 rather than W2K. Get your copy of GPMC.msi as a download from Microsoft's site. While I am assured that the GPMC will work on Windows 2000 Domains, I have not got it to run. (However, I have not tried that hard as I now prefer Server 2003.)

The GPMC unifies Group Policy management across your Active Directory forest. Before the GPMC, administrators needed multiple tools to manage Group Policy; the Microsoft Active Directory Users and Computers, the Delegation Wizard, and the ACL Editor. Not only does the GPMC integrate the existing Group Policy tools, but also it brings the following exciting new capabilities:

  • A user interface that makes it easier to create and edit each Group Policy.
  • New WMI filtering means that you can apply policies to particular machine, or only if there is enough disk space.
  • Interfaces to Backup, restore, import, and copy Group Policy Objects (GPOs).
  • Simplified management of Group Policy-related security.
  • Reporting for GPO settings and Resultant Set of Policy (RSoP) data.

Offline Installers Of .NET Frameworks all versions


The main purpose of offline installers is to save bandwidth.

Here is the set of links on Microsoft servers from where we can download the offline installers of .NET Framework 3.5, .NET Framework 3.5 Service Pack 1, .NET Framework 3.0 and .NET Framework 2.0.

.NET Framework Client Profile Offline Installer

.NET Framework 3.5 Setup

.NET Framework 3.5 Setup Service Pack 1

.NET Framework 3.0 Setup

.NET Framework 2.0 Setup

Want to Fix Issues about Linux, Networking?


Tech Support Forum home to more then 136,000 problems solved.

  • Issues have included: Spyware, Malware, Virus Issues, Windows, Microsoft, Linux, Networking, Security, Hardware, and Gaming Getting your problem solved is as easy as:
  • Registering for a free account
  • Asking your question
  • Receiving an answer

Registered members can get
  • Get free support
  • Communicate privately with other members (PM).
  • Removal of this message
  • See fewer ads.
  • And much more..

Top Alternatives to Microsoft Office


Microsoft Office (MS Office) dominates the office suite market, but that doesn’t mean it’s the only option. Here is the Top alternatives to Microsoft Office products.

  • Corel WordPerfect
  • Sun StarOffice
  • OpenOffice – Free
  • iWork
  • IBM Lotus Symphony – Free
  • ThinkFree Office 3
  • Google Docs & Spreadsheets – Free (online)
  • Zoho Office – Free (online)
  • SSuite Office

How to Change User Password at Command Prompt


How to use the net user command to change the user password at a Windows command prompt. Only administrators can change domain passwords at the Windows command prompt. To change a user's password at the command prompt, log on as an administrator and type: "net user * /domain" (without the quotation marks)

When you are prompted to type a password for the user, type the new password, not the existing password. After you type the new password, the system prompts you to retype the password to confirm. The password is now changed.

Alternatively, you can type the following command: net user . When you do so, the password changes without prompting you again. This command also enables you to change passwords in a batch file.

Non-administrators receive a "System error 5 has occurred. Access is denied" error message when they attempt to change the password

Setting Up a Secure Guest Account


By default, the Guest account has access to your computer's programs, to files in the Shared Documents folder, and to files in the Guest profile. But no password is required to use the account, so you'll want to be sure that the Guest account doesn't expose items that a casual user shouldn't see or modify. In fact, the default settings place pretty tight restrictions on the Guest account, but you should ensure that these rather obscure settings are still in place:

Prevent network logon by the Guest account.
This prevents a user at another computer from using the Guest account to log on over the network. In Local Security Settings (Secpol.msc), open Local Policies, User Rights Assignment. Be sure that Guest is listed in the Deny Access To This Computer From The Network policy.

Do not include Guest in this policy if you use Simple File Sharing and you are sharing your computer's folders or printers. Simple File Sharing requires the use of the Guest account for network access.

Prevent a Guest user from shutting down the computer.
In Local Security Settings, open Local Policies, User Rights Assignment. Be sure that Guest is not listed in the Shut Down The System policy. (Even with this policy in place, anyone-including guests-can shut down the computer from the Welcome screen. You can set a policy that allows only a logged-on user to shut down the computer. To do that, open Local Policies, Security Options and disable the Shutdown: Allow System To Be Shut Down Without Having To Log On policy.)

Prevent a Guest user from viewing event logs.
In Registry Editor, open HKLM\System\CurrentControlSet\Services\Eventlog. Visit each of the three subkeys-Application, Security, and System-and be sure that each contains a DWORD value named RestrictGuestAccess set to 1.

Quick SHUTDOWN



1. Open Task manager (By Ctrl+Alt+Del or R.click on the taskbar and select Task manager)

2.Hold Ctrl + Shift and select Shutdown menu and click Turn Off

Direct Bootup Without Typing Password



1. At a command prompt, type "control userpasswords2" and press Enter.

2. On the Users tab, clear the Users Must Enter A User Name And Password To Use This Computer check box and then
click OK.
3. In the Automatically Log On dialog box that appears, type the user name and password for the account you want to be logged on each time you start your computer.

NTLDR (or) NTDETECT.COM not found


1. Copy NTLR and NTDETECT.COM files from /I386 folder of windows XP CD to "C:\".

Note: For FAT partition use Win 98 Start up disk.
Incase of NTFS partition use Win 2000 CD Recovery console or "NTFS 4 DOS"

HAL.DLL missing or corrupted


This problem is due to misconfigured "Boot.ini" file.

solution:
1. Boot using Windows XP CD and Select Repair
2."Bootcfg /list" use this command to verify Boot.ini file.
3. "Bootcfg /rebuid" use this command to repair Boot.ini file now restart the computer.

Joining a workgroup through scripting

Microsoft removed from the utility netdom.exe the ability to join a computer to a workgroup. However, they kept on their FTP server the good old one shipped with Windows NT4.

Grab it and keep it near your usual tools, it’s still useful. For example, i’m using it in a script in order to do a domain rejoin of a workstation.