Hope this helped you resolve the error “The ordinal 410 could not be located”.

Check the network

Prior to working on the network, I suggest you download the Windows Server 2003 Support Tools to the old server from http://www.microsoft.com/downloads/details.aspx?FamilyId=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en. Once installed on the old server, you can run the command dcdiag from a command prompt, which tests the Domain Controller and verifies there are no present issues in Active Directory. This way, you can fix those issues before migrating. If all tests are passed, and only when all tests are passed, you should then run netdiag to test the network configuration of the server, and again ensure all tests pass before proceeding.

Install the new server

Firstly, install Windows Server 2003 to the new server. If you have the R2 edition, install Disk 2 of the CD-Rom media after initial setup completed and the system is up and running.
Once the new server is up and running, install drivers for the Network Card and any other necessary drivers. Then, once a Network Connection can be seen on the server and you can communicate over the network, configure the server with a static IP address on your network. At this stage, set the Preferred DNS Server to be the IP address of (one of) the existing Domain Controller(s). Do not enter any ISP DNS servers here.
Next, join the server to the existing Active Directory Domain. This is performed the standard way – in the same way as you join a workstation – through Start, Control Panel, System, Computer Name, Change. Choose the Domain option, enter the Domain Name and then press OK. A restart is required at this stage.

Prepare the Domain

If you will be installing Windows Server 2003 into a Windows Server 2000 domain, or Windows Server 2003 R2 into a non-R2 Server 2003 domain, you need to extend the schema. This involves placing the Windows Server 2003 media into the Domain Controller which currently holds the Schema Master FSMO role. For Windows Server 2003 R2, you must enter Disk 2, for other editions, enter Disk 1. For Windows Server 2003, browse, on the Schema Master, to the drive:\i386 folder at a command prompt. For R2 edition, browse on Disk 2 to the drive:\CMPNENTS\R2\ADPREP folder at a command prompt.
Once in the directory, the command dir should show the list of files available, one of which should be the adprep.exe tool. At the prompt, you should execute the command adprep /forestprep, to extend the forest schema. Once replication between all Domain Controllers in the Forest has completed – any only when that has occurred – you should then execute adprep /domainprep via the same procedure, and again, wait for replication to take place before proceeding.

Promote the server

After the reboot, you can now invoke the dcpromo wizard, used to promote the server as a Domain Controller. Start the wizard by entering dcpromo into the Start, Run box, then press OK. When prompted whether to enable Advanced Mode, I suggest unless you wish to see Advanced Features that you do not enable this feature. Follow through the wizard, opting for the ‘Additional Domain Controller in an existing domain’ when prompted. When the wizard completes, it will install Active Directory Services onto the server. Do NOT press ‘Cancel’ at this stage. If you made a mistake, wait for the wizard to complete, when you can restart the server and re-run the dcpromo wizard to correct the issue.

Install DNS

DNS is a crucial part of Active Directory, used for the whole of the Active Directory system. As a result, we must migrate DNS from the old DC to the new DC.
The easiest route to do this is to use Active Directory-integrated DNS, so that the DNS replicates from Domain Controller to Domain Controller with Active Directory replication traffic. To check whether your DNS zones are Active Directory-integrated, look on your existing Domain Controller in the DNS console (Start, Control Panel, Administrative Tools, DNS). Under Forward Lookup Zones, look for <yourdomainname.com> in the list. Beside the zone in the ‘Type’ column, you should see ‘Active Directory-integrated’ noted. If it does not report this, right-click the zone, choose Properties, then on the General tab beside Type, press the Change button and check the box marked ‘Store the zone in Active Directory’. Press OK.
Now the zone is stored in Active Directory, we simply need to install DNS on the new Domain Controller, and the DNS information will replicate in due course. To install DNS on the new server: Start, Control Panel, Add/Remove Programs, Add/Remove Windows Components. Click ‘Networking Services’, then press the Details button. Check the box to enable ‘Domain Name System (DNS)’ and then press OK. Pressing Next will install the new roles you have checked (DNS, in this case).
Once DNS is installed, it could take a short amount of time before the data shows up in the DNS console on the new server. However, it will show up in due course, so be patient; you don’t even need to manually create the zones.

Global Catalog

In a single-domain, single-forest environment, all Domain Controllers should be Global Catalog servers. The Global Catalog contains a partial replica of all objects in the forest, and is used to establish Universal Group Membership at logon. Without it, logins may not work properly, if at all. Thus, the new server should be a Global Catalog server.
To achieve this, on either the old or the new server, open the Active Directory Sites and Services tool from Administrative Tools in Control Panel. In the tool, expand the site which owns the server, then expand the server object itself. Within the server object, you will see an object entitled ‘NTDS Settings’. Right-click on this, press Properties and then check the box marked ‘Global Catalog’. OK out, and then it is necessary for replication to take place before the server will become a full Global Catalog.

FSMO Roles

The final step is to transfer the FSMO Operations Roles from the old server to the new server. The Operations Roles dictate the DC which performs particular Active Directory tasks. For example, the Schema Master role dicates upon which server the Schema can be extended.
To transfer these roles to the new server, follow the instructions in this Microsoft Knowledgebase article: http://support.microsoft.com/kb/324801. Note: Verify any information you read is based on the TRANSFER of the roles. SEIZING is not applicable here, and should not be performed for a graceful DC migration.

DNS Server on the new server

At this stage, DNS should have replicated, so you should now set the Preferred DNS Server on the New Server’s Network Card to point to the IP of the new server, and that IP address only. Do not enter any ISP DNS servers. It is recommended you use the full IP address of the server, rather than the loopback 127.0.0.1 address.
You may wish to enable Forwarders in the DNS console. Since no workstation or server should have the ISP’s DNS server manually configured on its NIC, the forwarder at the server enables DNS on the server to resolve the IP address of external domains using the ISP’s DNS server. See http://technet.microsoft.com/en-us/library/cc773370.aspx for details

Test

Finally, before demoting the old server, I would shut down or unplug the old server from the network, then test network resources and verify everything – particularly logins – works properly. You may find that the workstations are still detecting the DNS Server as the old server. This would need to be manually overridden to be the new server for test purposes.

Demote

If everything is working, then you can, at this stage, reconnect the old server, boot it up and then run dcpromo and choose the options to demote the server. Before disconnecting it from the network fully, you must remember that data and any other applications on the server must be transferred to the new server. ROBOCOPY is a good tool for doing this, since the /COPYALL switch enables you to copy the NTFS ACLs along with the actual data (Windows’ standard Copy operation will not carry the security permissions over).

Hope this helps

Depending on your background, you may find different sections of the newly published Microsoft Security Intelligence Report (SIR) to be of more interest.  In today’s post, we would like to highlight the section on infection rates based on the operating system (OS) version and the service pack level.  Microsoft has consistently observed that machines with newer OS and with more recent service packs are less likely to be infected by malware.  The graph below shows the number of computers having malware removed per 1,000 executions of the MSRT on that OS/SP during the second half of 2008 (2H08).

In the SIR, you will find the the following conclusions based on this data:

• The infection rate for Windows Vista is significantly lower than that of its predecessor, Windows XP, in all configurations.
• Comparing the latest service packs for each version, the infection rate of Windows Vista SP1 is 60.6 percent less than that of Windows XP SP3.
• Comparing the RTM versions of these operating systems, the infection rate of the RTM version of Windows Vista is 89.1 percent less than that of the RTM version of Windows XP.
• The infection rate of Windows Server 2008 RTM is 52.6 percent less than that of its predecessor, Windows Server 2003 SP2.
• The higher the service pack level, the lower the rate of infection. This trend can be observed consistently across client and server operating systems.

There are two reasons for this:

1. Service packs include all previously released security updates. They can also include additional security features, mitigations, or changes to default settings to protect users.
2. Users who install service packs generally maintain their computers better than users who do not install service packs and may also be more cautious in the way they browse the Internet, open attachments, and engage in other activities that can open computers to attack.

Server versions of Windows typically display a lower infection rate on average than client versions. Servers tend to have a lower effective attack surface than computers running client operating systems as they are more likely to be used under controlled conditions by trained administrators and to be protected by one or more layers of security. In particular, Windows Server 2003 its successors are hardened against attack in a number of ways, reflecting this difference in usage.

Continue http://blogs.technet.com/mmpc/archive/2009/04/21/malware-distribution-across-operating-systems.aspx

There are two main things that you have to do to schedual Powershell scripts.

1. Allow Interactive Commands using set-executionpolicy command.
2. Put Powershell script in a ".ps1" file. You can use any text editor to make this.

The first thing you need to do is make sure that Powershell is set to execute Powershell scripts, instead of only allowing interactive commands to be run in the Powershell environment.

Type the following at the Powershell command prompt:

set-executionpolicy RemoteSigned

This will allow the system to run Powershell scripts that are created locally (Remote Powershell scripts that may be downloaded must be signed).

Once this is done, you can create your Powershell script using notepad. Just make sure you name the file with an extension of .ps1 . Now to run the script outside of its Powershell environment you type a command similar to the following:

powershell -command "& 'MyScript.ps1' "

Just put the above command into a .bat or .cmd file and schedule it like you would normally schedule a script to be run with Windows task scheduler.

Group policies are the way to control a 2000, XP or 2003 system. But they have something of a black box-ish feel to them in that they’re hard to troubleshoot despite the XP and 2003 "resultant set of policy" (RSOP) tools. But even then, RSOP tools are most useful in an Active Directory-based domain with centralized group policies, and not everyone has an AD.

Sometimes I want to take a system and wipe it clean of any domain or local group machine policies, to essentially reset its state to "just installed." As policies live in several places, that’s not as easy as it sounds. Here’s what I’ve found useful.

There is no one single place where policies live. When you fire up gpedit.msc or Local Security Policy (secpol.msc), then you’re directly tweaking items in many parts of the Registry, as well creating or modifying data in \windows\system32\GroupPolicy. (It’s a hidden directory, so set Folder Options to show hidden files and folders if you want to look in it. And if you’re running Windows 2000, then the directory is \winnt\system32\GroupPolicy.)

Most of the changes to machine policies seem to live in HKEY_LOCAL_MACHINE\Security and HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft, as well as a file named Registry.pol in \windows\system32\GroupPolicy\Machine. Here are the basic steps that I’ve found allow me to reset a system to almost new:

• Reset HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft to an out-of-the-box state by restoring a copy taken from a freshly-installed system.
• Delete \windows\system32\GroupPolicy\Machine\Registry.pol, if it exists.
• Run the Setup Security template.

Here’s more detail on the rollback steps.

Every XP, 2003 and 2000 system includes a security settings template at \windows\security\templates\setup security.inf. (Again, 2000 systems will use \winnt, not \windows.) Apply the template from the command line like so:

secedit /configure /db junk /cfg "c:\windows\security\templates\setup security.inf" /overwrite /quiet

In that command — which should be typed as all one line — you’re telling secedit to use a template named "c:\windows\security\templates\setup security.inf" to create a security database called "junk" and to overwrite any existing security databases called "junk." We’re only doing this because secedit can’t directly apply a security template; it must first create the security database, and then it applies the security database.

This command make take a bit of time to run; run Task Manager and you’ll see secedit.exe in the list of running processes while it’s working. (Or leave off the /quiet and it’ll yammer at you while it’s working.)

Applying that template will reset many security settings, but not, unfortunately, all. For example, software restriction policies will not be rolled back, and IPSec filters won’t be restored to their initial state just by running "setup security.inf." To roll those back, we’ll restore a Registry key, HKLM\Software\Policies\Microsoft. That’s the key where most of the policy information lives. The easiest way to roll back most of policies, then, is to restore this key to its pristine state. And the easiest way to do that is to grab a HKLM\Software\Policies\Microsoft key from a newly-installed system, or for that matter one that hasn’t had any policy work done on it. (But before you do all this work, check your system — if you never messed with IPSec or software restriction policies then simply applying the template might have done the "policy reset" trick for you.)

The easiest way to do that is to open up Regedit on your newly-installed system and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies, where you’ll see a folder icon labeled "Microsoft." Right-click it and choose Export, then point Regedit at someplace to put the file. For my example, I’ll call it policies.reg, but you can put it anywhere you like — just remember wherever you put it. I then copy the policies.reg file to the computer that I want to reset policies on; for the sake of example, let’s say that I store it in c:\oldreg.

Now, I don’t want to just apply that Registry file to my system, as .reg files really only merge information into the Registry — I want to reset that part of the Registry altogether. So before I apply policies.reg to my system’s Registry, I’ll first delete the current HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft key in the Registry. (As always, PLEASE be careful when messing with the Registry!) You can either do that by opening up Regedit, navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Policies, clicking on the Microsoft folder and pressing Del, or you can do it from the command line:

reg delete hklm\software\policies\microsoft /f

Now I’m ready to apply the Registry fixes either by double-clicking on policies.reg, or from the command line like so:

regedit /s c:\oldreg\policies.reg

Finally, zap \windows\system32\GroupPolicy\Machine\Registry.pol either from Explorer or from the command line. Restart and the policies are gone! Let’s wrap that up into a step-by-step:

First, export the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft key from a "virgin" system; call the file policies.reg and store it on the system that you want to reset in a directory named c:\oldreg.

Second, create a batch file with the following lines in it, or just copy the lines from this document. Save the file, calling it resetpol.cmd. Store it and policies.reg on a floppy somewhere so they can be easily transported to any other system that might need its policies reset. If your system is a Windows 2000 system, then type "\winnt" where you see "\windows" below.

reg delete hklm\software\policies\microsoft /f
regedit /s c:\oldreg\policies.reg
secedit /configure /db reset /cfg "c:\windows\security\templates\setup security.inf" /overwrite /quiet
del c:\windows\system32\grouppolicy\machine\registry.pol

Finally, run resetpol.cmd. Wait for secedit to finish, then reboot.

How does this advice vary if you want to remove domain-based policies? Well, the best way to wipe out all domain-based policies is to simply unjoin the workstation from the domain. That seems to un-do most of the policies. But if you’ve got a system that’s not connected to the domain — perhaps a laptop — and you just want to be free of domain policies temporarily, then follow the above advice. Of course, you’ve got to be a local administrator to do any of this policy un-doing.

One final note: each of those commands resets a part of policies. But they may not reset them all — that’s why I said "almost new." If you’ve created a custom policy that "tattoos" the Registry, then there’s no way to roll back those changes unless you’ve documented what the policies did in the first place; then you can reset the affected Registry keys one at a time. So be careful with those Registry tattoo-ers!