Note The four parameters in each error message vary.
When this problem occurs, information that describes the error is saved in the System log. The information resembles the following:
Event Type: Warning Event Source: USER32 Event Category: None Event ID: 1076 User: User Computer: Computer Description: The reason supplied by user User for the last unexpected shutdown of this computer is: System Failure: Stop error Reason Code: 0x805000f Bug ID: Bugcheck String: 0x00000024 (0x0019033d, 0xb9958014, 0xb9957d10, 0xf70c1299) Comment: 0x00000024 (0x0019033d, 0xb9958014, 0xb9957d10, 0xf70c1299)
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.
If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:
Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
Prerequisites
To apply this hotfix, you must have Windows Server 2003 Service Pack 1 or Windows Server 2003 Service Pack 2 installed.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
How to obtain the latest service pack for Windows Server 2003
Restart requirement
You must restart the computer after you apply this hotfix.
Hotfix replacement information
This hotfix does not replace any other hotfixes.
File information
The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.
mscorsvw.exe is precompiling .NET assemblies in the background. Once it's done, it will go away. Typically, after you install the .NET Redist, it will be done with the high priority assemblies in 5 to 10 minutes and then will wait until your computer is idle to process the low priority assemblies. Once it does that it will shutdown and you won't see mscorsvw.exe. One important thing is that while you may see 100% CPU usage, the compilation happens in a process with low priority, so it tries not to steal the CPU for other stuff you are doing. Once everything is compiled, assemblies will now be able to share pages across different processes and warm start up will be typically much faster, so we're not throwing away your cycles.
If you are really want to get rid of mscorsvw.exe from your task manager, just do:
Please refer to the following document SMTP notification configured to be sent from Backup Exec for Windows Servers, requiring authentication to the SMTP server, fails to be sent http://support.veritas.com/docs/290886
Notifications configured to be sent with SMTP mail
SMTP (Simple Mail Transfer Protocol) notification is configured and enabled within Backup Exec but no notification is received after the job runs. http://support.veritas.com/docs/264683
After the Remote Desktop Session Host server (Terminal Server) runs for a while, there are many sessions marked as active in the Remote Desktop Services Manager (Terminal Services Manager). How to avoid this situation?
Answer
To reduce the number of active sessions, you may adjust the terminal server configuration based on the business requirement.
Configuration #1: Remote Desktop timeout settings
By using this configuration or policy setting, you can set the timeout limit for Idle session and Active session; meanwhile, you can end a session if the session times out.
1.Open the property dialog for RDP-Tcp connection in Remote Desktop Services Manager.
2.In the Sessions tab, you can configure the following settings:
·Active Session Limit
·Idle session limit
·Action when session limit is reached or connection is broken
·End a disconnected session
Configuration #2: Restrict each user to a single session
By using this configuration or policy setting, each user can only maintain one session to the certain terminal server; when another session is started by the same user, the original one will lose the connection. In that way, the total number of possible active sessions won’t exceed the total remote users. You can implement this method in 3 levels:
·RDP-Tcp configuration
Edit Settings – Restrict each user to a single session: Yes
·Local Group Policy
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services (Terminal Services)\Remote Desktop Services Session Host(Terminal Server)\Connections\Restrict Remote Desktop Services (Terminal Services) users to a single remote session: Enabled;
·Group Policy:
Similar location as above, depending on the specific OS version of the domain controller.
By specifying the minutes that the TS holds a remote session actually disconnected, the server will detect the session status after each period. The session that are actually offline will be changed to Disconnected status:
To implement this solution, there are two levels of ways:
·Local Group Policy:
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services (Terminal Services)\Remote Desktop Services Session Host(Terminal Server)\Connections\Configure keep-alive connection interval: Enabled and value specified
·Group Policy:
Similar location as above, depending on the specific OS version of the domain controller.
More Information
216783 You cannot completely disconnect a Terminal Server connection
Opened up the "Properties" of "RDP-tcp" in the connections tree and selected the "Network Adapter" tab
This is a licensing issue. W/o purchasing Terminal Services CALs you're limited just as you've seen to two (2) RDP connections.
(You can sort of cheat and get one more session, BTW, by using the "/admin" or "/console" switch on the Terminal Services client.)
Every time I need to set up a bunch of virtual machines, I have to go back and look up where to find the Sysprep tool and how to use it. Here are the details so I can find it in the future…
In case you haven’t encountered Sysprep before, it is a tool that allows you to create a base OS image (including Windows, Office, Visual Studio, or whatever other applications you want) and then re-package it. You can then create cloned disks (or just copy the whole thing) and when you boot the new disk, it is like booting Windows for the first time, except with all your software installed. You get to choose a new computer name, SIDs are regenerated, etc.
Each version of Windows requires the correct version of Sysprep. Where do you find the correct version of Sysprep? On your install disks in <DVD>:\Support\Tools\Deploy.cab. Although System Preparation tool for Windows Server 2003 Service Pack 2 Deployment claims to install the Sysprep tool, I’ve never been able to make it work on my system. So don’t bother wasting your time. Go to your original install media and grab the file from there.
Creating the Sysprep Image
Open <DVD>:\Support\Tools\Deploy.cab and extract setupcl.exe, setupmgr.exe, and sysprep.exe to C:\Sysprep. (N.B. C: is your system drive. If you installed Windows to another drive letter, use that drive letter rather than C:.)
Run setupmgr.exe from C:\Sysprep.
The Setup Manager wizard starts. Click Next…
Create new… Next…
Select “Sysprep setup”. Next…
Select the correct OS version… Next…
Select “No, do not fully automate the installation”… Next…
Enter Name and Organization, Time Zone, Product Key, and Workgroup or Domain. The other settings can remain defaulted. Note that you don’t want to specify the computer name since you will be creating multiple computers from the base image and you don’t want to specify the admin password, even encrypted. If the sysprep program can extract the password from the answer file, so can any hacker worth their salt. Click Next… through to the end.
Finish… Save to C:\Sysprep\sysprep.inf. OK…
Wait while Setup Manager finishes. Cancel… (Yes, odd way to exit a program that has completed successfully.)
Run sysprep.exe.
Click OK.
Ensure that “Don’t regenerate security identifiers” is UNCHECKED. You want to regenerate the SIDs when each new clone boots.
Click Reseal, OK to confirm that you want to regenerate SIDs, and wait for the system to shut down.
Creating a Cloned Server
If you’re using VMWare Workstation, create a linked clone of your Sysprepped server. (You can also create a new linked disk using VirtualPC using File… Virtual Disk Wizard and then creating a new VM using the linked disk.)
Change any VM settings such as memory. DO NOT change number of processors from 1 to 2 as the HAL (hardware abstraction layer) for uni-processor vs. multi-processor Windows is different. Your system will blue screen if you do this.
Boot the cloned server.
The Windows Setup wizard will appear. Next…
Accept the license agreement. Next…
Enter a new computer name and administrator password. Next…
Windows will boot and you can log in with the administrator password you just entered.
When prompted, click “Yes” to update your product activation.
Select “Yes, let’s activate Windows over the Internet now”. Next…
Select “No, I don’t want to register now; let’s just activate Windows”. Next…
OK…
Update this server… to go to Microsoft Update.
Once you’re ensured that your patches are up-to-date, you can close the browser and click Finish… then Yes… on the dialog to start using Windows.
You should now have a fresh copy of Windows. You can create as many cloned servers as you need for your mini-network.
Greetings, Todd here and I wanted to take a few moments to talk to you about an issue that arises from time to time. I will start this time-related issue exploration with a worst case scenario.
The Primary Domain Controller Emulator (also known as the PDCe) in your forest root has a hardware issue which requires the replacement of the motherboard or even the replacement of the machine due to theft, fire, water based fire suppression system damage, etc, etc… The motherboard or machine is replaced and the machine is started.
Sometime shortly after the motherboards or system replacement it is noted that AD replication is failing, everywhere. The error you are receiving is:
Description: It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime. Replication has been stopped with this source.
The reason that replication is not allowed to continue is that the two machine's views of deleted objects may now be different. The source machine may still have copies of objects that have been deleted (and garbage collected) on this machine. If they were allowed to replicate, the source machine might return objects which have already been deleted.
Time of last successful replication:
2004-10-27 08:59:52
Invocation ID of source:
154ef845-f894-054e-88fc-a205dcbff605 Name of source: 12345678-9abc-def1-1234-56789abcdef1._msdcs.domain.com
Tombstone lifetime (days): 60
So here is the breakdown of our time related AD replication failure: the motherboard that was replaced never had its time set in the BIOS, so the time the OS referenced was from 2003. It would probably be helpful for you to know that the OS, at startup, will read the BIOS CMOS clock and set the time within the OS to this value. When the machine booted up it read the BIOS time and proceeded to set the current system time to the new setting even though it was 5 years in the past.
This machine being the PDCe for the forest means that the other DC’s in the root and the other PDCe’s in the other domains in the forest will sync from it. So we have just managed to propagate a bogus time setting to all the other DC’s in the forest.
The PDCe at the root of the forest then syncs from its local or Internet time source and set the time properly and this new time setting is then propagated throughout the environment.
All the DC’s that replicated when the date was set back to 2003 after which we receive the current time and before replication we check to see when we last replicated. The last replication time date stamp shows 2003 so as far as the machine is concerned we have not replicated for 5 years which just slightly exceeded the 60 -180 day Tombstone lifetime.
Recovering from this AD replication error state can be ugly and time consuming, though we have methods to ultimately resolve it. Besides the initial AD replication failure due to the replication quarantine for replication partners that have not replicated for a period greater than that the tombstone lifetime the chances are very high that you will experience lingering objects. So the operative word here is prevention.
What we could have done to prevent or limit the DC’s from experiencing a large time offset? Here are some ideas:
1. Set the motherboard BIOS time to the current date and time before booting the operating system by powering the machine up and selecting the BIOS or system configuration settings.
2. Transfer or even seize the PDCe FSMO role to a different machine before reintroducing the PDCe with the replaced motherboard to the environment.
3. Implement KB 884776 - How to configure the Windows Time service against a large time offset. This will effectively prevent a machine from correcting it time offset beyond the hard upper and lower limits. If this is in place on the DC’s, Servers, and clients we would not see this scenario as a big problem.
One final comment concerning the circumstances of this issue occurring; anything that can change the time on a DC can cause this issue. BIOS on the motherboard being reset, the BIOS battery going bad, a poorly patched DC getting a virus which flips the time, a router or hardware based time solution being used as the central Network Time Protocol (NTP) time source, etc…
Hopefully you will never experience this type of issue since with a little forethought and configuration you will be able to completely prevent an otherwise difficult situation.
The DCPROMO (Dcpromo.exe) utility is used for promoting a server to a domain controller and demoting a domain controller to a member server (or to a standalone server in a workgroup if the domain controller is the last in the domain). As part of the demotion process, the DCPROMO utility removes the configuration data for the domain controller from the Active Directory. This data takes the form of an "NTDS Settings" object, which exists as a child to the server object in the Active Directory Sites and Services Manager.
The information is in the following location in the Active Directory:CN=NTDS Settings,CN=, CN=Servers,CN=,CN=Sites, CN=Configuration,DC=...
The attributes of the NTDS Settings object include data representing how the domain controller is identified in respect to its replication partners, the naming contexts that are maintained on the machine, whether or not the domain controller is a Global Catalog server, and the default query policy. The NTDS Settings object is also a container that may have child objects that represent the domain controller's direct replication partners. This data is required for the domain controller to operate within the environment, but is retired upon demotion.In the event that the NTDS Settings object is not removed properly (for example, the NTDS Settings object is not properly removed from a demotion attempt), the administrator can use the Ntdsutil.exe utility to manually remove the NTDS Settings object. The following steps list the procedure for removing the NTDS Settings object in the Active Directory for a given domain controller. At each NTDSUTIL menu, the administrator can type help for more information about the available options.
Caution: The administrator should also check that replication has occurred since the demotion before manually removing the NTDS Settings object for any server. Using the NTDSUTIL utility improperly can result in partial or complete loss of Active Directory functionality.
Procedure
Click Start, point to Programs, point to Accessories, and then click Command Prompt. At the command prompt, type
ntdsutil
and then press ENTER.
Type
metadata cleanup
and then press ENTER. Based on the options given, the administrator can perform the removal, but additional configuration parameters need to be specified before the removal can occur.
Type
connections
and press ENTER. This menu is used to connect to the specific server on which the changes occur. If the currently logged on user does not have administrative permissions, alternate credentials can be supplied by specifying the credentials to use before making the connection.
To do so, type
set creds domain nameusernamepassword
and press ENTER. For a null password, type null for the password parameter.
Type
connect to server servername
and then press ENTER. You should receive confirmation that the connection is successfully established. If an error occurs, verify that the domain controller being used in the connection is available and the credentials you supplied have administrative permissions on the server.
Note: If you try to connect to the same server that you want to delete, when you try to delete the server that step 15 refers to, you may receive the following error message:
Error 2094. The DSA Object cannot be deleted0x2094
Note: Windows Server 2003 Service Pack 1 eliminates the need for steps 3 and 4.
Type
quit
and then press ENTER. The Metadata Cleanup menu appears.
Type
select operation target
and press ENTER.
Type
list domains
and press ENTER. A list of domains in the forest is displayed, each with an associated number.
Type
select domain number
and press ENTER, where number is the number associated with the domain to which the server you are removing is a member. The domain you select is used to determine if the server being removed is the last domain controller of that domain.
Type
list sites
and press ENTER. A list of sites, each with an associated number, is displayed.
Type
select site number
and press ENTER, where number is the number associated with the site to which the server you are removing is a member. You should receive a confirmation listing the site and domain you chose.
Type
list servers in site
and press ENTER. A list of servers in the site, each with an associated number, is displayed.
Type
select server number
where number is the number associated with the server you want to remove. You receive a confirmation listing the selected server, its Domain Name Server (DNS) host name, and the location of the server's computer account you want to remove.
Type
quit
and press ENTER. The Metadata Cleanup menu appears.
Type
remove selected server
and press ENTER. You should receive confirmation that the removal completed successfully. If you receive the following error message:
Error 8419 (0x20E3) The DSA object could not be found
the NTDS Settings object may already be removed from the Active Directory as the result of another administrator removing the NTDS Settings object, or replication of the successful removal of the object after running the DCPROMO utility.
Note: You may also see this error when you attempt to bind to the domain controller that is going to be removed. Ntdsutil needs to bind to a domain controller other than the one that is going to be removed with metadata cleanup.
Type
quit
at each menu to quit the NTDSUTIL utility. You should receive confirmation that the connection disconnected successfully.
Remove the cname record in the _msdcs.root domain of forest zone in DNS. Assuming that DC is going to be reinstalled and re-promoted, a new NTDS settings object is created with a new globally unique identifier (GUID) and a matching cname record in DNS. You do not want the DC's that exist to use the old cname record.
As best practice you should delete the hostname and other DNS records. If the lease time that remains on Dynamic Host Configuration Protocol (DHCP) address assigned to offline server is exceeded then another client can obtain the IP address of the problem DC.
Now that the NTDS setting object has been deleted we can now delete the following objects:
Use ADSIEdit to delete the computer account in the OU=Domain Controllers,DC=domain...
Note: The FRS subscriber object is deleted when the computer object is deleted, since it is a child of the computer account.
Use ADSIEdit to delete the FRS member object in CN=Domain System Volume (SYSVOL share),CN=file replication service,CN=system....
In the DNS console, use the DNS MMC to delete the cname (also known as the Alias) record in the _msdcs container.
In the DNS console, use the DNS MMC to delete the A (also known as the Host) record in DNS.
If the deleted computer was the last domain controller in a child domain and the child domain was also deleted, use ADSIEdit to delete the trustDomain object for the child in CN=System, DC=domain, DC=domain, Domain NC.
Very basic rsync / cp backup rotation with hardlinks
Here's a very basic script that I use with RSync that makes use of hard links to reduce the overall size of the backup folder. The limitations are:
- Every morning, a server copies the current version of all files across SSH (using scp) into a "current" folder. There are two folders on the source server that get backed up daily (/home and /local).
- Later on that day, we run the following script to rsync any new files into a daily folder (daily.0 through daily.6).
- In order to bootstrap those daily.# folders, you have to use "cp -al current/* daily.2/" on each, which fills out the seven daily backup folders with hardlinks. Change the number in "daily.2" to 0-6 and run the command once for each of the seven days. Do this after the "current" folder has been populated with data pushed by the source server.
- Ideally, the source server should be pushing changes to the "current" folder using rsync. But in our case, the current server is an old Solaris 9 server without rsync. Which means that our backups are likely to be about 2x to 3x larger then they should be.
- RDiff-Backup may have been a better solution for this particular problem (and we may switch).
- This shows a good example of how to calculate the current day of week number (0-6) as well as calculating what the previous day number was (using modulus arithmetic).
- I make no guarantees that permissions or ownership will be preserved. But since the source server strips all of that information in the process of sending the files over the wire with scp, it's a moot point for our current situation. (rdiff-backup is probably a better choice for that.)
#!/bin/bash # DAILY BACKUPS (writes to a daily folder each day) DAYNR=`date +%w` echo DAYNR=${DAYNR} let "PREVDAYNR = ((DAYNR + 6) % 7)" echo PREVDAYNR=${PREVDAYNR} DIRS="home local"
for DIR in ${DIRS} do echo "----- ----- ----- -----" echo "Backup:" ${DIR} SRCDIR=/backup/cfmc1/$DIR/current/ DESTDIR=/backup/cfmc1/$DIR/daily.${DAYNR}/ PREVDIR=/backup/cfmc1/$DIR/daily.${PREVDAYNR}/ echo SRCDIR=${SRCDIR} echo DESTDIR=${DESTDIR} echo PREVDIR=${PREVDIR}
cp -al ${PREVDIR}* ${DESTDIR} rsync -a --delete-after ${SRCDIR} ${DESTDIR}
echo "Done." done
It's not pretty, but it will work better once the source server starts pushing the daily changes via rsync instead of completely overwriting the "current" directory every day.
The code should be pretty self explanatory but I'll explain the two key lines.
cp -al ${PREVDIR}* ${DESTDIR}
This overwrites all files in ${DESTDIR}, which is today, with the files from yesterday, but does it by creating hard links of all files. Old files which were deleted since last week will be left behind until the rsync step.
rsync -a --delete-after ${SRCDIR} ${DESTDIR}
This then brings today's folder up to date with any changes as compared to the source directory (a.k.a. "current"). It also deletes any file in today's folder that don't exist in the source directory.
Taking another stab at setting up RSync and SSH on our Windows 2003 servers. The goal is that we can upload web files to a central server and then have it synchronize the other servers in the array. Once again, I'm going to use the cwRsync and copSSH packages (latest version is 2.0.9).
Installation on a Windows 2003 Domain Controller:
Download cwRSync, open up the ZIP file, then extract/run cwRsync_Server_x.x.x_Installer.exe.
Click "Next" to move past the splash screen
Click "I Agree" to move past the license screen
Select both the "Rsync Server" and "OpenSSH Server" (unless you have already installed and configured SSH) then click "Next"
Choose your installation location, the default is "C:\Program Files\cwRsyncServer"
Click "Install" to begin the installation process
cwRsync will install and create a default service account with a randomly generated password.
Write down the service account password.
Click "Close" when the install has finished.
So now if you look in "Active Directory Users and Computers", there should be a newly created account called "SvcwRsync". Since we are installing this on a domain controller, you should rename this account to "SvcwRsync_SERVERNAME" so that it doesn't cause problems for other installations. You'll also need to change the login details for the "RsyncServer" and "OpenSSH SSHD" services.
Once you have things configured, make sure to go to the Services control and set the services to start up automatically. I also recommend configuring the Recovery tab so that the services are automatically restarted after 2 or 5 minutes.
...
Now to start locking things down. First, I'm going to restrict what interfaces (IP addresses) that the cwRSync service can listen on by adding an address line to rsyncd.conf.
address = 127.0.0.1
One the machine that you will be using to talk to the rsync daemon on the host server, you'll also need the cwRsync tools installed along with OpenSSH. Because the rsync daemon can only listen on 127.0.0.1 (localhost), we'll need to create an SSH tunnel from the client machine to the host server before we can talk to the rsync daemon.
One the client machine:
1. Create a new folder under "C:\Program Files\cwRsyncServer\home" for the new user. In my particular case, I'm calling my user "backuppull" because I am pulling backup files off of the rsync server and down to my local machine.
2. Create a ".ssh" folder under that new home folder.
3. Open up a command window (Start, Run, "cmd") and change directories to the home folder ("C:\Program Files\cwRsyncServer\home\backuppull")
4. Create ssh keys for this user. Since we want to do this sync in a batch file without user-interaction, they'll need to be created with null passwords. You may wish to use the "-b 2048" option to create stronger keys (recommended for RSA, DSA can only be up to 1024 bits).
5. You will now need to transfer the public key files to the host server. Again, you will create a new home directory for the user in the "C:\Program Files\cwRsyncServer\home" folder tree along with creating a ".ssh" folder under that home folder. The two files that need to be copied are:
id_dsa.pub id_rsa.pub
6. Now append the contents of these files to the ".ssh/authorized_keys" file on the host server.
type id_dsa.pub >> authorized_keys type id_rsa.pub >> authorized_keys
7. Now to configure SSHD on the host server. You will need to find and edit the sshd_config file (probably in "C:\Program Files\cwRsyncServer\etc"). The following changes should be made in the current version default settings.
I'll need to come back and revisit this link, from a glance, it looks very well laid out and will be exactly what I want to pattern my backup systems after.
Note: These directions are works-in-progress... in fact, they might not even work at all. I got side-tracked before I could finish this and will re-visit it at some point in the future.
The folks who created cwRSync (www.itefix.no) have now released a package called copSSH which is basically SSH for windows and works with cwRSync. I'll be refering back to my old post about installing cwRSync. The latest version I have is from late April 2005 and includes bug fixes for Windows Server 2003.
These steps are for installing rsync in a server configuration (meaning that it will be listening on the listed ports). Since the install process needs to (optionally) create an user account and create a new service, you'll need administrative access to the machine that you are using. (I'm not sure whether members of the Power Users group have enough privileges.)
Download cwRSync, open up the ZIP file, then extract/run cwRsync_x.x.x_Installer.exe.
Click "Next" to begin the install.
Read and agree to the licence.
Make sure that both the client and server components are checked off and click "Next".
Choose your installation location. I prefer to put mine in a custom location (C:\bin\cwRsync).
Click "Install" to begin the installation.
The default user account is "cwrsync" (with a random password) and it will be installed as a service. You will probably want to change the password to something stronger and adjust the properties of the service in Computer Management. Specifically, I changed the Recovery tab to auto-restart the service after 5 minutes if it dies. I've left the "auto-start" setting to "manual" until I've finished configuration and testing.
By default, the newly created "cwRSync" folder grants permissions to the Administrators group (full control), the CWRSYNC user account (full control) and the Users account (read/execute).
Now you should configure your rsyncd.conf file.
Now we need to install copSSH.
Download copSSH, open up the ZIP file, then extract/run copSSH_x.x.x_Installer.exe.
Click "Next" to begin the install.
Read and agree to the licence.
Change the install folder to match where you installed cwRSync (C:\bin\cwRsync). (This is according to the FAQ on the itefix.no web site.)
This creates a new service called "OpenSSH SSHD" with a default users account of "SvcCOPSSH"
You will probably want to change the password to something stronger and adjust the properties of the service in Computer Management. Specifically, I changed the Recovery tab to auto-restart the service after 5 minutes if it dies. I've changed the "auto-start" setting to "manual" until I've finished configuration and testing.
Notice that the copSSH installation blows away existing permissions on the c:\bin\cwRSync folder. This may require fixing (I have to test first).
Re-start the SSHD service in manual mode (if you stopped it earlier).
Note: The following probably doesn't work (probably missing a package, or the fact that I have GNU's unix tools for Win32 installed is problematic), but I might come back and make it work later so I'm leaving it here for now. I ran into trouble when trying to configure SSH. Right now, I've gone back to my original plan of either hacking apart the Cygwin files and manually copying only the DLLs and EXEs that I need or using the OpenSSH for Windows project at SourceForge.
1. Run the Cygwin setup.exe file and start the instllation. I chose to install to "c:\bin\cygwin", but left the rest of the options "as-is". Pick your mirror (use the Cygwin public mirrors page to find one close to you).
2. On the "Select Packages" screen, select the "Curr" option and make sure it says "Category" next to the "View" button at the top. The installation dialog is (finally) re-sizeable, so stretch it out or maximize it so you can see all of the columns.
3. Beside the "+All" category, it will say "Install", "Uninstall", ... click on the word until all of the categories say "Uninstall". (Note: These steps assume that you're doing a new Cygwin install and that you don't already have Cygwin installed.) Now we can start picking the minimum number of packages required to setup SSH and RSync.
4a. Under the "+Admin" category, you'll need to install the "cygrunsrv" package (click once on the "Skip" indicator under the "New" column). This will turn on a few other packages that this package depends on (mostly under the "+Base", "+Libs", and "+Shells" categories).
4b. Open up the "+Net" category and select the "rsync" and "openssh" packages. You'll also end up with "openssl" which is required in order to use "openssh".
5. Click the "Next" button to start downloading and installing the packages. If the download fails, choose another mirror, double-check your package selections (my copy remembered which packages I had already selected), and try again. The base install size required around 7MB of downloads and expanded out to 24MB (34MB actual due to a 4KB cluster size).
6. Fire up the cygwin shell, you should see a command-line window open with a "$" prompt. Try out a few unix commands (pwd, ls, whoami) to see if things are working.
7. Further steps... (I'll cover these in future posts)
a) Setup your rsync.conf file (in the "etc" folder) b) create a service account for use by the rsync service c) create a Windows service using the "cygrunsvc" tool d) setup OpenSSH and then re-configure rsync to use it
Hacking together a minimal rsync for windows installation
Based on what I've read elsewhere (links in my previous posting), I think I can pull the relevant pieces out of the Cygwin package. I'll try to keep good notes as to what worked and what didn't, but let me know if you find any errors. Rsync wrapper for Win32 seems to be a good starting point for which DLLs and files I'll need to pull out of the standard Cygwin release.
You can download the files off of any of the Cygwin public mirrors. Grab the following archives and extract them to a temporary directory on your machine.
release/cygwin/cygwin-1.5.10-3.tar.bz2 - contains the DLL file (usr/bin/cygwin1.dll) and a lot of base utilities
release/popt/libpopt0/libpopt0-1.6.4-4.tar.bz2 - contains the usb/bin/cygpopt-0.dll file
Test out whether you've gotten rsync working (thanks to "Aaron Johnson's page about rsync" for showing me what command line options to use). To do this, type the following commands:
If you have a log file, there should now be an entry indicating that rsync has started up and is listening on the default port (tcp/873). Looking at the processes in Windows Task Manager, you should see the "rsync.exe" process. You should also now test out some rsync transfers from another workstation to verify that your security settings and module settings are correct.
To do: - create the user account to use for the rsync service - setup rsync to run as a service (need the SRVANY.EXE file, I think) - figure out how to get rsync talking through an SSHD server
This is a follow-up to my previous post about Securing cwRSync. We were using the "cwRSync package", but when running in server mode it doesn't know how to talk to clients over an SSH-encrypted connection. Which isn't a big deal if you're only talking to other servers on the local network, but is problematic in cases where you have to be wary of eavesdropping (across WiFi links or untrusted networks like the internet). So I've been looking off-and-on over the past month at figuring out how to get an rsync service running using SSH on a Windows server.
One option is to install the full Cygwin package. Which is a bit much for a server (or rather, I'm not comfortable installing Cygwin on a server... yet).
At the office we're working on setting up cwRSync on the web server array to push the daily web/ftp/smtp log files back to a central point for archiving. Right now, since all of the web servers are on the same LAN segment at the hosting facility, we're just sending the plain text data across the wire to the rsync port (tcp/873). Since the previous solution was to use FTP to move the log files around, it's no worse then the old solution from a security standpoint. (It is, however, much faster and more efficient.) Security is handled solely thorugh the rsyncd.conf "hosts allow" setting (only the internal IP addresses are allowed to be used to transfer the data) with no passwords or shared keys.
However, since the next step is that we want to setup pulling those log files automatically back to the main office, we need to look into locking it down further and putting encryption in place (e.g. routing rsync traffic over an ssh tunnel).
After digging around a bit here's what I've found:
The cwRSync Servicedoes not support SSH, so there's no way to connect securely to a rsync server that is using cwRSync as its daemon. Future releases are expected to add ssh support for cwRSync servers. Locking down through IP address and username/password is the limit of what you can do for security, all traffic is in the clear (unless you have IPSec between the two machines).
However, you can use cwRSync in a client-configuration and route the traffic over SSH to a SSH-capable rsync server.
That being said, I'm going to explore some other packages. All of which will either require that cygwin be installed, or at least that certain cygwin DLLs be installed.
Links:
Rsync wrapper for Win32 - Uses the cygwin DLLs, but doesn't require a full cygwin install, includes SSH.
The instructions over at cwRSync's install page are a bit vague, so I'm going to jot down the steps that I use. These steps are for installing rsync in a server configuration. Since the install process needs to (optionally) create an user account and create a new service, you'll need administrative access to the machine that you are using. (I'm not sure whether members of the Power Users group have enough privileges.)
Download cwRSync, open up the ZIP file, then extract/run cwRsync_x.x.x_Installer.exe.
Answer "Yes" when asked if you want to continue with the install.
Answer "Yes" when asked if you want to install cwRSync as a Windows Service.
Specify the installation folder where you want to install cwRSync. My personal preference is "c:\bin\cwrsync" instead of the default since our servers already have various command line tools installed under c:\bin.
Enter the account name and password of the local user account that you are going to use for the cwRSync service. It's a good idea to use a seperate account for the cwRSync service, but you may also specify an existing account name.
The upload area can be set to anything. In fact, you'll probably be removing whatever you set here when you configure your rsyncd.conf file. For now, set it to be a sub-folder under where you installed the cwRSync executables to.
Click the "Install" button. The installer will then create the folder where cwRSync is being installed to, (optionally) create the user account for the cwRSync service, and it will set restrictive permissions on the install folder so that only the service's user account has rights.
That takes care of the basics. If you want, view the installation details prior to exiting the install program and cleaning up. Read the instructions on the popup dialog.
Next, we need to finish setting up the RSync service in Windows.
Right-click on My Computer, pick "Manage".
In the left panel, scroll down and open up the "Services and Applications" tree, then select "Services".
Locate the "RsyncServer" service and double-click to open up the properties dialog.
"General" tab: Change the "Startup type" setting to "Automatic".
"Log On" tab: Re-type the password for the user account that you're using. Click the "Apply" button to save your changes and Windows will popup a notification that the user account has been granted the rights to logon as a service.
"Recovery" tab: Change these to match your preferences. My personal preference is to restart the service on the first two failures, do nothing on subsequent failures, reseting the fail count after 1 day and restarting the service after a delay of 30 minutes.
Click "OK" to save and exit.
Don't start the service yet, the rsyncd.conf file needs to be configured first.
You need to configure the rsyncd.conf file and set up your first "module" (a.k.a. a share path). Find your rsyncd.conf file (it's in the folder where you installed cwRSync to) and open it up in a text editor (NotePad works). Now, go read the official rsyncd.conf help page. Read it twice if it's your first time, because it's possible to put a very large gaping security hole into your setup if you're not careful. The default settings at the top of the file are fine, but you may wish to change the "hosts allow = *" to "hosts allow = (your client machine IPs)" as a preventative first step. Then, even if you screw up the other security mechanisms, you've at least limited which IP addresses an attacker can base an attack from. (You can test this by telnet'ing to port 873 and seeing whether the rsync service drops your connection.)
Next, we need to start setting up "modules" in the rsyncd.conf file. "Modules" are basically the same concept as a Windows share, except that you have to use rsync to access the files within the "module". Ignore what it says on the cwRSync install page about rsync modules having to be sub-directories under the cwrsync folder. If you grant correct directory permissions to the cwRSync service account, then the service daemon will be able to read or read/write to the target folders without problems.
The default module installed is called "test". Go ahead and comment it out with '#' symbols and save the file. From my (limited) testing, it does not appear to be necessary to restart the rsync service in order for it to see changes in the rsyncd.conf file.
[test]
path = /cygdrive/c/cwrsync/data
read only = false
transfer logging = yes
There are two basic ways to use rsync and this will affect how you grant permissions to the rsync service account.
The first is a read-only ("pull") setup, where the clients can only pull files from the rsync server. The rsync service account should only have Read & Execute / List Folder Contents / Read permissions for the folder tree that you are going to publish. In addition, when you setup your module in the configuration file, you should specify "read only = true" as a setting.
The second is a "push" setup where clients are writing changes to the rsync server. The rsync service account will require "modify" permissions for the shared directory tree. Under your module configuration section in the rsyncd.conf file, a "push" setup must have "read only = false".
Now, for every directory tree on the rsync server that you wish to share, create a new module section (e.g. "[logs]" or "[web]" or "[joes_backup]"). Verify that the cwRSync service account has proper permissions to the file system tree. Then add the following options (at a minimum) below the module section name:
[joes_backup]
path = /cygdrive/e/backup/joe
read only = false
That allows any client who manages to authenticate with the rsync service to write the E:\Backup\Joe on the rsync server. That is not exactly secure and you should take additional steps to lock it down through the use of "hosts allow", "auth users", "secrets file" and perhaps ssh. Securing your box is a bit beyond the scope of this post. It's also a bit beyond my experience level since I'm just getting started with rsync.
Treat this occurrence as a lingering object condition, and do the following:
Run the repadmin /showrepl command on the domain controller that received the error to determine which domain controller has been disconnected for longer than a tombstone lifetime.
Restart replication on the destination domain controller. After you remove lingering objects, you must restart replication on the domain controller that logged the event by editing the registry setting that allows replication with a potentially out-of-date domain controller. You can also perform this procedure if you do not want to wait to remove lingering objects and you want to start replication immediately.
Reset the registry to protect the domain controller against outdated replication. After replication has resumed on the domain controller that logged the event, reset the registry so that this domain controller continues to log events if replication is attempted with a domain controller where the last successful replication occurred longer than a tombstone lifetime ago.
Restart Replication Following Event ID 2042
To restart inbound replication on the destination domain controller following event ID 2042, you must edit the Allow Replication With Divergent and Corrupt Partner registry entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
Use the following procedure to change the registry entry value. This procedure does not require a restart of the domain controller to take effect.
DC=w2k8,DC=local Vancouver\W2K8AD1 via RPC DSA object GUID: ad9c2f9d-1236-43cd-9c79-cea6eb7d945a Last attempt @ 2010-05-22 21:48:53 failed, result 8614 (0x21a6): The directory service cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime. 169 consecutive failure(s). Last success @ 2009-09-26 15:02:24.
CN=Configuration,DC=w2k8,DC=local Vancouver\W2K8AD1 via RPC DSA object GUID: ad9c2f9d-1236-43cd-9c79-cea6eb7d945a Last attempt @ 2010-05-22 21:47:10 failed, result 8614 (0x21a6): The directory service cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime. 8 consecutive failure(s). Last success @ 2009-09-26 14:50:50.
CN=Schema,CN=Configuration,DC=w2k8,DC=local Vancouver\W2K8AD1 via RPC DSA object GUID: ad9c2f9d-1236-43cd-9c79-cea6eb7d945a Last attempt @ 2010-05-22 21:47:10 failed, result 8614 (0x21a6): The directory service cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime. 8 consecutive failure(s). Last success @ 2009-09-26 14:45:17.
DC=DomainDnsZones,DC=w2k8,DC=local Vancouver\W2K8AD1 via RPC DSA object GUID: ad9c2f9d-1236-43cd-9c79-cea6eb7d945a Last attempt @ 2010-05-22 21:47:10 failed, result 8614 (0x21a6): The directory service cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime. 15 consecutive failure(s). Last success @ 2009-09-26 14:45:17.
DC=ForestDnsZones,DC=w2k8,DC=local Vancouver\W2K8AD1 via RPC DSA object GUID: ad9c2f9d-1236-43cd-9c79-cea6eb7d945a Last attempt @ 2010-05-22 21:47:10 failed, result 8614 (0x21a6): The directory service cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime. 8 consecutive failure(s). Last success @ 2009-09-26 14:45:17.
Source: Vancouver\W2K8AD1 ******* 162 CONSECUTIVE FAILURES since 2009-09-26 15:02:24 Last error: 8614 (0x21a6): The directory service cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.
Removes lingering objects - an object stored in Active Directory that has seen, deleted and garbage collected by a reference DC but continues to incorrectly exist on direct or transitive replication partners DC's that have not inbound replicated knowledge of the objects deletion within tombstone lifetime number of days.
The PC running repadmin may have Windows Vista or Windows Server 2008 installed, and must have network connectivity to all domain controllers targeted by the parameter.
The reference DC must host a writeable copy of the directory partition targeted for lingering object removal and have network connectivity to all domain controllers targeted by the parameter.
DC's targeted by the parameter may host read-only or writeable copies of directory partition targeted for lingering object removal.
DC's and Global catalogs targeted by continue to advertise and service ldap request during lingering object removal.
The reference DC and domain controllers targeted by the parameter may have Windows Server 2003, Windows Server 2003 R2 or Windows Server 2008 installed.
There are no domain or forest functional requirements for this command.
ADVISORY_MODE is a test mode that logs NTDS Replication events 1938, 1946 and 1942 in the targeted domain controllers' directory service event log identifying the lingering objects that should be removed but does not actually remove them.
Lingering objects are removed when "repadmin /removelingeringobjects" is run without the /advisory_mode switch. NTDS Replication events 1937, 1945 and 1939 logged on the target DC's directory services event log identify the start, conclusion and set of objects removed from a directory partition.
You should conceptually think of DC's in the as the "bad" DC's that you want to test or remove lingering objects from and as the "reference" DC.
Microsoft recommends enabling strict replication consistency before removing lingering objects.
[SYNTAX]
/removelingeringobjects [/ADVISORY_MODE]
[EXAMPLES]
The following command would check the Europe NC on all DC's in the site HQ for lingering objects using the DC specified by its ObjectGUID 667f7037-8198-4357-8f15-8f709f04b6e2 as reference.
The /ADVISORY_MODE will cause events to be written to the Directory Service Event Log for each of the target DC's indicating how many lingering objects were found.
The following command would check and remove lingering objects from the Europe NC on DC dubdc03 using the DC specified by ObjectGUID 667f7037-8198-4357-8f15-8f709f04b6e2.
C:\Users\Administrator.W2K8>repadmin /removelingeringobjects w2k8ad2.w2k8.local ad9c2f9d-1236-43cd-9c79-cea6eb7d945a DC=w2k8,DC=local RemoveLingeringObjects successful on w2k8ad2.w2k8.local.
C:\Users\Administrator.W2K8>repadmin /removelingeringobjects w2k8ad2.w2k8.local ad9c2f9d-1236-43cd-9c79-cea6eb7d945a CN=Configuration,DC=w2k8,DC=local RemoveLingeringObjects successful on w2k8ad2.w2k8.local.
C:\Users\Administrator.W2K8>repadmin /removelingeringobjects w2k8ad2.w2k8.local ad9c2f9d-1236-43cd-9c79-cea6eb7d945a CN=Schema,CN=Configuration,DC=w2k8,DC=local RemoveLingeringObjects successful on w2k8ad2.w2k8.local.
C:\Users\Administrator.W2K8>repadmin /removelingeringobjects w2k8ad2.w2k8.local ad9c2f9d-1236-43cd-9c79-cea6eb7d945a DC=DomainDnsZones,DC=w2k8,DC=local RemoveLingeringObjects successful on w2k8ad2.w2k8.local.
C:\Users\Administrator.W2K8>repadmin /removelingeringobjects w2k8ad2.w2k8.local ad9c2f9d-1236-43cd-9c79-cea6eb7d945a DC=ForestDnsZones,DC=w2k8,DC=local RemoveLingeringObjects successful on w2k8ad2.w2k8.local.
C:\Users\Administrator.W2K8> To restart replication following event ID 2042 1. Click Start, click Run, type regedit, and then click OK. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
3. If the registry entry does not exist, create the entry as follows: 1. Right-click Parameters, click New, and then click DWORD Value. 2. Type the name Allow Replication With Divergent and Corrupt Partner, and then press ENTER. 3. Double-click the entry. In the Value data box, type 1, and then click OK. Reset the Registry to Protect Against Outdated Replication When you are satisfied that lingering objects have been removed and replication has occurred successfully from the source domain controller, edit the registry to return the value in Allow Replication With Divergent and Corrupt Partner to 0.
Use Mosh instead of SSH
-
Mosh is a replacement for SSH. It's more robust and responsive, especially
over Wi-Fi WiFi, cellular, and long-distance links.
*On Ubuntu:*
# add-apt-repo...
V2V Communications security considerations
-
The future of vehicles, road infrastructure and driving are changing. We
are progressing with vehicle-to-vehicle (V2V) and vehicle-to-infrastructure
(V2I) ...
