1.1. Linux - General Command Lines

Linux - General Command Lines

Note: You MUST be at the ROOT user to make/save any changes. Linux users, your distribution will determine the location of your network config file which will need to be updated and saved in order for the changes to remain in effect after rebooting. Network cards are referred to as eth0, eth1, eth2, etc based on their position on the PCI bus.

Display Current Config for all NIC's: ifconfig

Display Current Config for eth0: ifconfig eth0

Assign IP: ifconfig eth0 192.168.1.2

Assign IP/Subnet: ifconfig eth0 192.168.1.2 netmask 255.255.255.0

Assign Default Gateway: route add default gw 192.168.1.1

Assign multiple IP's: ifconfig eth0:0 192.168.1.2

Assign second IP: ifconfig eth0:1 192.168.1.3

Disable network card: ifconfig eth0 down

Enable network card: ifconfig eth0 up

View current routing table: route "or" route -n

View arp cache: arp "or" arp -n

Ping: ping -c 3 192.168.1.1

Trace Route: traceroute www.whatismyip.com

Trace Path: tracepath www.whatismyip.com

DNS Test: host www.whatismyip.com

Advanced DNS Test: dig www.whatismyip.com

Reverse Lookup: host 66.11.119.69

Advanced Reverse Lookup: dig -x 66.11.119.69

1.2. DOS / Windows IP Command Lines

DOS / Windows IP Command Lines

Display Connection Configuration: ipconfig /all

Display DNS Cache Info Configuration: ipconfig /displaydns

Clear DNS Cache: ipconfig /flushdns

Release All IP Address Connections: ipconfig /release

Renew All IP Address Connections: ipconfig /renew

Re-Register the DNS connections: ipconfig /registerdns

Change/Modify DHCP Class ID: ipconfig /setclassid

Network Connections: control netconnections

Network Setup Wizard: netsetup.cpl

Test Connectivity: ping www.whatismyip.com

Trace IP address Route: tracert

Displays the TCP/IP protocol sessions: netstat

Display Local Route: route

Display Resolved MAC Addresses: arp

Display Name of Computer Currently on: hostname

Display DHCP Class Information: ipconfig /showclassid

2.1. How to Setup VPN on XP

The following will guide you through setting up a VPN connection on Windows XP to an established VPN server.

1. Open the Windows Control Panel.
   
   
2. Open the Network Connections item in Control Panel. A list of existing dial-up and LAN connections will appear.
   
   
3. Choose the 'Create a new connection' item from the left-hand side of the window. The Windows XP New Connection Wizard will appear on the screen.
   
   
4. First click Next to begin the wizard, then choose the 'Connect to the network at my workplace' item from the list and click Next.
   
   
5. On the Network Connection page of the wizard, choose the 'Virtual Private Network connection' option and click Next.
   
   
6. Enter a name for the new VPN connection in the 'Company Name' field and click Next. The name chosen need not match the name of an actual business.
   
   
7. Choose an option on the 'Public Network' screen and click Next. The default option, 'Automatically dial this initial connection' can be used if the VPN connection will always be initiated when the computer is not already connected to the Internet. Otherwise, choose the 'Do not dial the initial connection' option. This option requires that the public Internet connection be established first, before this new VPN connection will be initiated.
   
   
8. Enter the name or IP address of the VPN remote access server to connect to, and click Next. Company network administrators will provide this information.
   
   
9. Choose an option on the "Connection Availability" screen and click Next. The default option, 'My Use Only,' ensures that Windows will make this new connection available only to the currently logged on user. Otherwise, choose the 'Anyone's use' option.
   
   
10. Click Finish to complete the wizard. The new VPN connection information has been saved.

Tips:

1. While no practical limits exist on what may be entered in the 'Company Name' field, choose a connection name that will be easy to recognize later.
   
   
2. Take special care to key the VPN server name/IP address data correctly. The Windows XP wizard does not automatically validate this server information.

3.1. Creating individual client folders on the ReadyNAS

1. Log in to your ReadyNAS as administrator at https://IP_address/admin.
    
2. In the left navigation bar, click Security > User & Group Accounts.  Select Manage Groups from the pull down menu on the right side of the window, and click the Add Group tab.  Add an access group for each client share.
   
3. Next, click Shares > Add Shares, and enter the name of the client folders you wish to add.  Leave Public Access checked to allow full access from inside your network.
   
4. Go to Shares > Share Listing and click the grey icon in the HTTP/S column corresponding to one of the shares just created.  In the next window, select Read/Write in the Default access pull-down menu, click the first checkbox in the Share Access Restrictions window, and add the matching group name in the Groups allowed access box.  Repeat for each share added.
   
5. Click Security > User & Group Accounts.  Select Manage Users from the pull down menu on the right side of the window, and click the Add User tab.  Create user accounts for the new shares and assign them to the matching access groups.  User names cannot match share or group names.
   

4.1. Frequently Asked Questions About Logon Scripts

Frequently Asked Questions About Logon Scripts

1. How do I setup Logon scripts in a domain with Active Directory?

There are two ways to assign Logon scripts. First, you can specify the Logon script on the “Profile” tab of the user properties dialog in the Active Directory Users and Computers MMC. Second, you can specify a Logon script in Group Policy.

2. Why would I choose one method over another?

You would assign a Logon script on the "Profile" tab of the user properties if you have client computers with Windows 95, Windows 98, Windows ME, or Windows NT. Group Policy is not applied on computers with these operating systems. If all of your clients have at least Windows 2000, you could use Group Policy to assign Logon scripts.

3. Can I use both methods to assign Logon scripts?

You can, but if a user logs on to a computer with Windows 2000 or above, both Logon scripts will run.

4. How do I setup Logon scripts so they support all of my clients?

If your users can Logon to both older clients (like Windows 95, Windows 98, Windows ME, or Windows NT) and the newer clients (like Windows 2000 and Windows XP), you should assign a batch file as the Logon script on the "Profile" tab for each user in the Active Directory Users and Computers MMC. The batch file can launch a VBScript program, as explained below. Once all of your clients are at least Windows 2000, you can use a VBScript program as the Logon script, and use Group Policy to assign Logon scripts to all users in a domain, site, or organizational unit.

5. How do I configure a Logon script for a user on the "Profile" tab in AD Users & Computers?

The field labeled “Logon script” on the “Profile” tab of the user properties dialog in the Active Directory Users and Computers MMC corresponds to the “scriptPath” attribute of the user object. The default location for Logon scripts specified by this attribute is the NetLogon share. By default, all users have read access to this share. The NetLogon share on the Domain Controller is located in the following folder:

%SystemRoot%\sysvol\sysvol\<domain DNS name>\scripts

where %SystemRoot% is usually “c:\winnt” and <domain DNS name> is the DNS name of the domain, similar to “MyDomain.com”. This folder is replicated to all Domain Controllers in the domain. The usual practice is to enter the name of the Logon script, for example “NetLogon.bat”, in the field labeled “Logon script” on the “Profile” tab for the user and place this file in the NetLogon share. The Logon script will run for the user when they Logon to any computer that is joined to the domain. You can also enter a UNC path in the “Logon script” field and place the file in another location. However, this location should be one that is replicated to all Domain Controllers. Alternatively, you can use a script or utility to assign the Logon script to the “scriptPath” attribute of the user object in Active Directory. A VBScript program to assign a value to this attribute for many users in bulk would be much faster than manually entering values for users one at a time in the MMC.

6. What languages can I use for Logon scripts?

If the client operating system (OS) is Windows 95, Windows 98, or Windows ME, the Logon script must be a batch file (with extension .bat) or executable program (with extension .exe). If the client OS is Windows NT, the Logon script can be a batch, command, or executable file (with extension .bat, .cmd, or *.exe). If the client is Windows 2000 or above, the Logon script can be a batch file, a command file, executable program (with extension *.bat, *.cmd, *.exe), or a program written in a language hosted by Windows Script Host (WSH). Examples of WSH supported languages are VBScript (with extension *.vbs) and JScript (with extension *.js). The type of Logon script you use should support all clients you expect the user to Logon to. However, a VBScript, JScript, or other WSH hosted program would be the most powerful. Other languages supported by WSH are Perl, REXX, and Python. However, the script engines for these languages must be registered with Windows. VBScript and JScript are installed on all clients with Windows 2000 or above, and is installed with DSClient on all other clients.

Another option that should be mentioned is KiXtart. This tool was available in the NT Server resource kit and provides logon script functionality for all clients.

7. Can I use a VBScript program for a Logon script on all clients in my domain?

Yes. The client operating system must be at least Windows 2000 in order for the actual specified logon script to be a VBScript program. All older clients should have a batch file defined as the Logon script. If any of your clients have Windows 95, Window 98, Windows ME, or Windows NT, it is recommended that you designate a batch file as the logon script for all users. Fortunately, the batch file can simply launch a VBScript program. The only requirement is that Windows Script Host (WSH) and VBScript be installed on the client. Clients with Windows 2000 or above come with WSH and VBScript. WSH and VBScript are installed with DSClient on Windows 95, Windows 98, and Windows ME. The DSClient for Windows NT also includes WSH and VBScript. There is also a separate installation of WSH and VBScript available if you don’t want to install DSClient on your Win9x or NT machines. However, if you install WSH and VBScript instead of DSClient on machines with Win9x or NT, you cannot use ADSI to retrieve information from Active Directory, such as group membership information. ADSI is built into clients with Windows 2000 or above.

An example of a batch file Logon script that launches a VBScript program is as follows:

@echo off

wscript %0\..\NetLogon.vbs

The “%0” in the batch file is interpreted by the command processor to be the name and path of the current file, which is the batch file itself. The string “%0\..\” then becomes the folder where the batch file is stored. The batch file above will launch the VBScript program NetLogon.vbs as long as it is saved in the NetLogon share with the batch file. This syntax is preferable to a UNC path, because it does not hard code the name of a Domain Controller. The syntax will work no matter which Domain Controller authenticates the user. The logon script will work no matter which Domain Controllers are available or where in the network the user logs on.

8. How do I configure a Logon script with Group Policy?

Logon scripts can also be configured in Group Policy. However, Group Policy only applies to clients with Windows 2000 or above. The setting in Group Policy is “User Configuration”, “Windows Settings”, “Scripts (Logon/Logoff)”, “Logon”. Best practice is to copy the file you want for the Logon script to the Windows clipboard, open the “Logon” setting in the Group Policy editor, press the “Show Files...” button, and paste the desired file in the dialog. You can select the file and edit it in this dialog as well. This is easier than navigating in Windows Explorer to the folder where Group Policy Logon scripts are saved. However, if you do have to navigate to the folder, the path on the Domain Controller is:

%SystemRoot%\sysvol\sysvol\<domain DNS name>\<policy GUID>\user\scripts\logon

Again, %SystemRoot% is usually “c:\winnt” and <domain DNS name> is the DNS name of the domain, similar to “MyDomain.com”. <policy GUID> is a hexadecimal string representing the GUID (unique identifier) of the specific Group Policy Object (GPO). Group Policies are assigned to a domain, site, or organizational unit in Active Directory. The Logon script setting applies to all users in the domain, site, or organizational unit to which the GPO applies. You will notice that you assign a Logon script to all users in the container at once, rather than having to assign the “scriptPath” attribute for each user. This makes it much easier to assign Logon scripts to many users. However, since the same Group Policy applies to all users in the domain, site, or organizational unit, you must code the Logon script to accommodate all users.

9. What about Logoff, Startup, and Shutdown scripts in Group Policy?

Group Policy can also be used to assign Logoff, Startup, and Shutdown scripts. The Logoff script setting in Group Policy is “User Configuration”, “Windows Settings”, “Scripts (Logon/Logoff)”, “Logoff”. Similar to the Logon script setting, it applies to all users in the domain, site, or organizational unit that the GPO is assigned to. Startup and Shutdown scripts are in “Computer Configuration”, “Windows Settings”, “Scripts (Startup/Shutdown)”. These scripts are applied to any computer in the domain, site, or organizational unit that the Group Policy is applied to. There is no provision for running Logoff, Startup, or Shutdown scripts on computers with Windows 95, Windows 98, Windows ME, or Windows NT.

10. What permissions are required for Logon scripts to run?

Logon and Logoff scripts run with the credentials of the user. It is recommended that the group “Domain Users” be given permission to any resources used by either of these scripts. For example, if the Logon or Logoff script writes to a log file, the group “Domain Users” should be given read/write access to the file or the folder where the log file is located. Most users have limited privileges on the local computer, so Logon and Logoff scripts will have the same limited privileges.

Startup and Shutdown scripts run with the credentials of the computer object. It is recommended that the group “Domain Computers” be given permission to any resources used by the Startup or Shutdown scripts. However, Startup and Shutdown scripts have System privileges on the local computer. This gives Startup and Shutdown scripts access to the local file system and registry.

If you plan to make any configuration or desktop changes with Logon or Startup scripts, remember that changes to the user (or to the HKEY_CURRENT_USER hive of the local registry) should be made in Logon scripts. Changes to the computer (or to the HKEY_LOCAL_MACHINE hive of the local registry) should be made in a Startup script.

11. What can be done with a batch file Logon script, besides launch a VBScript program?

A batch file Logon script can connect drives to network shares, connect to shared printers, and run command line utilities. Anything you can do at a command prompt can be done in a batch file. For example, a batch file Logon script that maps a drive to a network share and connects to a printer could be similar to below:

@echo off

net use H: \\MyServer\MyShare

net use LPT1: \\MyServer\MyPrinter

However, a batch file by itself cannot use ADSI to retrieve information from Active Directory. Unless you use a third party utility, there is no way to determine group membership. One third party tool that does provide the ability to check group membership is KiXtart. The Windows NT resource kit also provides the utility IfMember, which can be used to test for group membership in a batch file. However, IfMember only works on clients with NT or above.

12. What about Logon scripts in an NT domain?

The above discussion applies to networks with Active Directory. The Domain Controllers can be either Windows 2000 Server or Windows Server 2003, and the domain can be at any functional level. However, Logon scripts can also be used in NT domains. The default location for Logon scripts on the PDC or BDC in NT domains is:

%SystemRoot%\system32\repl\import\scripts

The Logon script is assigned on the Profile tab of the user management tool. The corresponding user attribute exposed by the WinNT provider is “loginScript”.

The Logon script can be a batch file, command file, or VBScript, with the same restrictions as discussed above with regard to the client OS. However, since the NT SAM account database is not LDAP compliant, a VBScript program cannot use the LDAP provider. VBScript Logon script programs in NT domains must use the WinNT provider.

5.1. Endpoint Folder Size Issue

If you are using Endpoint and the folder size starts to grossly enlarge, then follow the steps below to quickly reduce the folder size:

1. Removed the contents of
   C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Inetpub\content
2. Edit the following file: C:\Program Files\Symantec\Symantec Endpoint Protection Manager\tomcat\etc\conf.properties
3. Add at the end of that file the following: scm.lucontentcleanup.threshold=2
4. Restart the Symantec Endpoint Protection Manager service

You will then need to download the updated version.  This was directly from Symantec Support:

You can download the software (MR 2 MP 1) from
Https://fileconnect.symantec.com

Following is the link to Release Notes Or the Improvements in Symantec Endpoint Proctection
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007121216360648

The download site REQUIRES a vaild SN