sudo apt-get install nagios-nrpe-server

next, we should check and make sure that the service is actually running. We can do this two ways
sudo ps -Al | grep nrpe

This will show a line where the process is started. If it just comes back without stating anything something is wrong. Another check is to make sure you machine is listening on the nrpe port

netstat -an | grep 5666

Next, we need to set up the Nagios server to be able to check our machine.

sudo nano /etc/nagios/nrpe.cfg

and change

allowed_hosts=127.0.0.1

to

allowed_hosts=127.0.0.1,x.x.x.x

where “x.x.x.x” is the ip address of your nagios server. Now restart the nrep daemon so it reloads the settings

sudo /etc/init.d/nagios-nrpe-server restart

Now go on the Nagios server and run the following command

/usr/local/nagios/libexec/check_nrpe -H y.y.y.y

where “y.y.y.y” is the ip address of the machine you just installed nrpe on. If it works it will respond with the version of NRPE you just installed on the machine.

That’s it!

After some research, I found that there is basically two products that are currently the best for Anti-virus: NOD32, and Kaspersky. The are VERY similar – both have something like a 99.8% detection rate, and both leave a very small footprint. Supposedly NOD32 is just a bit less overhead than Kaspersky, but the latter is easier to administer. Seeing that I would rather be able to tell what my anti-virus program is doing in a corporate environment that get a marginal 1% increase in performance, we went with Kaspersky. Let me say that I don’t regret it one bit as it has already detected over 100 viruses, trojans, and other spyware that Symantec apparently had let slip by.

In any case, the uninstallation of Symantec was quite a chore. I found a few articles on how to remove it using some Symantec tools – but the tools (just like the Antivirus product) were either not present or didn’t function properly. Next I found an article on how to manually remove Symantec by running the uninstall wizard from a command prompt. After reviewing how this worked for a bit, I wrote a short vb script that basically finds the registry key for the Symantec Endpoint Protection, and then issues the command to uninstall the program. It also leaves entries into the Application event log on what the script is currently doing.

Be aware that as soon as the uninstall is completed, the computer will reboot (it took about 2-3 minutes on average for the uninstall to complete). Note also that sometimes the script can say that it failed to remove the program, I think that just happens because the computer reboots before it can send the “ok” back to the uninstall script (Basically as long as the shield is gone, it’s removed).

Once you have the script, you simply set it up to run as a script to run through Group Policy. Create a new Group Policy and then do Computer Configuration–>Windows Settings–>Scripts–>Startup. Then just add the script. This will make the uninstallation of Symantec occur the next time the computers under that Group Policy are started up. You probably should send an email to those users though and inform them that you are removing Symantec and that upon the next reboot of their computer it wil automatically reboot again after two to three minutes of starting up (again, since the Symantec reboots the machine after it is uninstalled).

One last note – make sure you remove the uninstall password from the program, otherwise the uninstall script will fail to uninstall the program.

Anyways, hopefully this can help someone else – I found it rather useful myself.

Option Explicit
 
const HKEY_LOCAL_MACHINE = &H80000002
 
dim ProductName, ProductKey
 
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sub GetSymantecProductKey()
 
dim oReg, sPath, aKeys, sName, sKey
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
 
sPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
oReg.EnumKey HKEY_LOCAL_MACHINE, sPath, aKeys
 
For Each sKey in aKeys
	oReg.GetStringValue HKEY_LOCAL_MACHINE, sPath & "\" & sKey, "DisplayName", sName
	If Not IsNull(sName) Then 
		if (sName = "Symantec Endpoint Protection") then
			ProductKey = sKey
			ProductName = sName
		end if
	end if
Next
 
end sub
 
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sub RemoveSymantec(key, name)
 
dim cmd, objShell, iReturn
cmd = "C:\windows\system32\msiexec.exe /q/x " & key
 
set objShell = wscript.createObject("wscript.shell")
 
objShell.LogEvent 0, "Removing the program [" & name & "] under Product Key [" & key & "]" & vbCrLf & "Executing command: " & vbCrLf & cmd
 
iReturn=objShell.Run(cmd,1,TRUE)
 
if (iReturn = 0) then
	objShell.LogEvent 0, "Program [" & name & "] was successfully removed"
else
	objShell.LogEvent 0, "Failed to remove the program [" & name & "]."
end if
 
Set objShell = Nothing  
 
end sub
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ProductKey = ""
ProductName = ""
 
call GetSymantecProductKey()
if Not (ProductKey = "") then
	call RemoveSymantec(ProductKey, ProductName)
end if

Step 1: Creating a Key Container

In order to secure your web.config, you will first need to create a key container in order to hold the private keys for the encrypted material. This is done with the following command line

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pc "MyConnectionStrings" -exp

where “MyConnectionStrings” is the name of the key container you wish to create. After creating a key container, you can now modify your web.config to support the encrypted sections.

Removing a key collection

At any point you can also remove a key collection, however doing this will mean that your web application will not be able to decrypt your connection strings anymore, and you will not be able to decrypt the connection strings file yourself for changes (see section 4.1).

The command to remove a key collection is

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pz "MyConnectionStrings"

Step 2: Setting up the web.config

In order to let ASP.NET know about the encryption provider (a.k.a. – which private keys to use to read the encrypted data), you must add the following section into your web.config under the section.

<configProtectedData defaultProvider="MyProvider">
	<providers>
		<add name="MyDBProvider"
		type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
		keyContainerName="MyConnectionStrings" cspProviderName=""
		useMachineContainer="true" useOAEP="false" />
	</providers>
</configProtectedData>

The key things to note are the defaultProvider=”MyProvider”, the name=”MyDBProvider” and the keyContainerName=”MyConnectionStrings”. The Provider name can be whatever you wish, and you may have multiple providers if you wish. The provider can be set in code on the ConnectionManager.ConnectionStrings().Provider, but if a default one is specified via the “defaultProvider” attribute, this does not need to be specified. Normally you would only use multiple providers if you want to have your connection strings split into multiple documents. Just as a note – other things can be encrypted in the web.config besides the connection strings section, in which case multiple providers may be useful as well. The keyContainerName MUST be the same name as the key container name you used in Step 1.

Step 3: Move connection strings into a different configuration file

Now that we have done this, we can encrypt our connection strings. Before we do this though, I would advise moving your connection strings out to an external file. The reason is a) All the connection strings will be kept separate from your web.config settings and b) The encryption tool parses and re-writes the web.config file, and if you have done any special formatting to make your web.config look nice, that formatting may be completely removed.

Doing this is rather simple, all you have to do is create another configuration file for your project (we will be using “ConnectionStrings.config” ) and moving your <connectionStrings> settings to that file. So before doing this you may have

Web.config

<configuration>
  ...
	<connectionStrings>
		<clear/>
		<add name="MyDBConn"
			connectionString="Data Source=MySQLSvr;Initial Catalog=AdventureWorks;User Id=MyUser;Password=MyPass;"
			providerName="System.Data.SqlClient" />
        </connectionStrings>
...
</configuration>

Now you will have
Web.config

<configuration>
...
        <connectionStrings configSource="ConnectionStrings.config"></connectionStrings>
...
</configuration>

ConnectionStrings.config

<connectionStrings>
	<clear/>
	<add name="MyDBConn"
		connectionString="Data Source=MySQLSvr;Initial Catalog=AdventureWorks;User Id=MyUser;Password=MyPass;"
		providerName="System.Data.SqlClient" />
        </connectionStrings>
</connectionStrings>

Step 4: Encrypting your connection strings

Next you need to encrypt the file where you are keeping the connection strings. This is done with the following command

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pef "connectionStrings" "PATH"

Where “PATH” is the full path to the folder where your web.config is stored. i.e. “C:\inetpub\wwwroot”. It does not matter where the “connectionstrings.config” file is found as the web.config now has the file location of the connectionstrings.config in it, and the program will follow that path to the external file. The best idea is still to put the connectionstring.config file in the same directory as the web.config though. After doing this, you should be able to open the ConnectionStrings.config and see that the information has changed to some encrypted data.

Decrypting your connectionstrings.config

Should the need arise for some changes to come to your connectionstrings, you can simply decrypt the file by executing the command

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pdf "connectionStrings" "PATH"

Step 5: Give ASP.NET access to the private key

The next command to run is to give the ASP.NET service access to the private key for it to be able to decipher the web.config file. By default the “NT Authority\Network Service” is the owner of the ASP.NET worker process, however this can be changed so you may need to grant the permissions to a different account instead. Giving access is done using the following commands:

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pa "MyConnectionStrings" "NT Authority\Network Service"
c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pa "MyConnectionStrings" "ASPNET"

Again, the “MyConnectionStrings” MUST be the name of the key container that you named in Step 1. At this point your application should now have access to use the ConnectionStrings.config in it’s encrypted state.

Step 6: (Optional where applicable) Exporting the private keys to a different server

One final thing to note is that if you are running the application on some instance where the application will need to be run on multiple web servers with the same ConnectionStrings.config, you will need to export the private key container so that the same file can be used on different machines. This is accomplished via the following command

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -px "MyConnectionStrings" "C:\CustomKeys.xml" -pri

After copying the file over to the other server, you would run the command

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pi "MyConnectionStrings" "C:\CustomKeys.xml"

to import the keys. I believe you will still need to redo Step 5 again in order to grant permissions.

Step 7: Accessing the connection strings within the web application

The first thing to do in order to access the connection strings is you will need to add a reference to the project to System.Configuration. Although you can access some classes and objects in System.Configuration without adding a reference, the ASP.NET 2.0 connection strings configuration manager (which we will need) is not part of them. Once you add the reference, you simply add

VB.NET

Dim MyConnStr As String = System.Configuration.ConfigurationManager.ConnectionStrings("MyDBConn").ConnectionString

C#

string MyConnStr = System.Configuration.ConfigurationManager.ConnectionStrings["MyDBConn"].ConnectionString

to access the connection string, where MyDBConn is the name you gave the connection string. Note that is you have multiple providers or the provider for the connection strings is not the same as the default provider, you will need to add

VB.NET

1
2
3

Dim DBConn As New System.Configuration.ConnectionStringSettings("MyDBConn")
DBConn.ProviderName = "MyProvider"
Dim MyConnStr As String = DBConn.ConnectionString

C#

1
2
3

System.Configuration.ConnectionStringSettings DBConn = new System.Configuration.ConnectionStringSettings["MyDBConn"];
DBConn.ProviderName = "MyProvider"
string MyConnStr = DBConn.ConnectionString

F.A.Q

Q: I would like to add/update/remove a connection string in the file and I’ve already encrypted the file, how do I do this? I have multiple web servers
A: If you just a single web server, all you need to do is , change it how you need, and then encrypt the file again. If you have multiple web servers, you will need to perform this on one of your servers, and then you can just copy that file to the other servers as the other servers will already have the key and know how to read the encrypted file.

Getting started, we run a robocopy script first, which will copy over all the data. Robocopy is a Microsoft tool for copying files with all sorts of options for permissions and retrying, etc. If you are a system administrator, I suggest you get used to this tool. You have to get it in a windows resource kit (download from Microsoft) for pre-Vista Windows machines, but Microsoft included it in Windows 2008 and Vista already. Anyways, the exact robocopy command I used was…

“C:\robocopy.exe” “E:\DataShares” “\\newserver\h$\Data Shares” /Z /R:5 /COPYALL /MIR /FP /LOG+:E:\DataShares\DataShares.log /TEE /XF DataShares.log

Which will basically copy all the files, mirroring the directory structure, retry 5 times if there is a failure, and write it out to a log file. This also copied the security permissions so that those remain intact. Note that if you have a local user on the server with permissions, these will not copy over as the local user does not exist on the server you are moving to (and no, you cannot just re-create the same user name and expect it to work, you would need to copy over the exact guid user id, which to date I have not done so I don’t know if it’s possible). A complete listing of robocopy commands can be found here.

You can do this during work hours as it shouldn’t effect anything. Some things may fail if they are in use, but that’s OK as we’ll get them later. When it comes time to do the actual move over, you write down the permissions on each of the shares, then stop sharing the folders. This will knock off any computer who is using a file inside those shares. Run the same robocopy script again, and this time it will only copy over new files or files that have been updated. For me, it took 7 hours to do the initial run through, but only 12 minutes to get the “incremental” update to all those files (600GB) – minimizing how long it took to do the actual move over. Once it’s done you should have 0 failures. If you have failures at this point, either free the locks (via server reboot or something) and/or make sure that you have permissions to all the folders with the user account you are running robocopy under (normally I find the latter is the problem though). Make sure you continue to run the robocopy script over and over until you have 0 failures, otherwise that means you are still missing files! After all the folders are copied successfully, you go to the new server and set back up the shares, using the same permissions you wrote down before. Next you edit any logon scripts that map drives to point to the new server.

The last thing to worry about is the users home directories. Since these are stored in Active Directory, you cannot just edit one text file like the logon scripts and hope to be done with it. You basically have two options A) Manually go to each user and edit the home directory B) use a tool and do all of them in one fell swoop. Obviously B is the better choice here. The tool we will use is called ADModify.NET, which is written by Microsoft. It is available for download here. It’s a pretty simple tool, you just start ADModify.exe, and then click “Modify attributes”. Pick your domain with the users you want to modify from the drop down list (make sure to pick the DC= entry, not the CN= entry). Then pick a domain controller – doesn’t matter which one, but preferably the one you consider you “main” DC, or one that has a global catalog. Uncheck everything except for “Show Only: Users” and uncheck “Show containers only”. Also check “Traverese Subcontainers (Subtree Search) at the bottom”. Now hit the Green arrow button to loa the list. Traverse the directory containers until you get to the folder containing the users you want to modify, then hit “Add To List>” at the bottom. Hold Ctrl and/or shift and select all the users, then hit “Next>>”. Now you will be at the normal Active Directory screen. Navigate to the “Profile” tab. Here you have the options to change the users home folder. Check the box next to “Connect” and change the drive letter to that of your choosing. Next you will want to change the path to the new path of your users’ home directory. For my company, we use a simple \\server\Home\UserAccountName structure. In this instance, where I want to modify multiple entries based off the user name, you put the path as

\\server\Home\%’sAMAccountName’%

The percent sign’s represent a variable, which will map the users account name when you hit continue. After you have it set up as you want, hit “Go!”. The script will run, and tell you the results, as well as write a little xml log file for your review later. Double check your changes in Active Directory Users and Computers, and then you’re all set. Note that you may want to test this on your account first just to make sure that you have the path right.

I decided to do this change at night time when it would effect the least amount of people, and I sent out an email saying that when users came in the next day (Monday) they would all need to reboot their computers or else things might not work correctly (as some programs are mapped to the shares, and also the logon scripts would need to be re-run). I also made sure to tell them to save and close anything they had open when they left the office for the last time before Sunday night, as I would be moving the shares and anything they didn’t save would be lost.

And that’s it – now I have all my shares and home directories running on a new machine, with minimal downtime and all permissions intact. The users aren’t even aware there was a change except for the fact that I made them reboot.