Install and Configure Python in Windows Server 2008/2003 (IIS 6.0 or 7.0)? 1. Install Python

1. Install Python

Go to Python official website http://www.python.org/download/ and download the latest Windows installer (.msi). Follow the screen and install it.

2. Configure IIS Web Service Extensions

Open Start -> Administrative Tools > Internet Information Services (IIS) Manager. Click "Web Service Extensions" and add a new web service 'C:\Python25\python.exe -u "%s" "%s"'.

3. Configure Website to Enable Python

Go to website that you want to eanble Phyton. Right click the website and go to Properties > Home Directory > Configurations > Mappings. Add a new script mapping ".py" with 'C:\Python25\python.exe -u "%s" "%s"'.

 

4. Test Python

Write a test file test.py and test it out. Everything should work now.

print
        print 'Status: 200 OK'
        print 'Content-type: text/html'
        print
        print ''
        print '
This is a header
'

        print '' #this is a comment
        print 'See this is just like most other HTML'
        print '
'
        print ''

5. Configure Control Panel (Optional)

If you have a control panel for your server, you may need to configure it as well. Below is a sample for Helm control panel.

    

Use policy to control bluecoat ProxySG administrator access

 If you would like to control administrator access to the ProxySG Management Console and CLI, you can create policy to configure administrator access privileges.

Using policy rules, you can require administrators to identify themselves by entering a username and password and specify whether read-only or read-write access is given. You can make this policy contingent on IP address, user name, group membership (if credentials were required), and many other conditions.

This solution assumes you have already configured users and groups for authentication (using RADIUS, LDAP, Microsoft Active Directory, or other authentication servers) and created a realm on the ProxySG to connect to these servers.

Procedure to follow

To create policy for ProxySG administrator access:

1. Launch the Visual Policy Manager.
2. Create an Admin Authentication layer (Policy > Add Admin Authentication Layer ).
3. In the Admin Authentication layer, specify the authentication realm that will be used to authenticate administrative users of the ProxySG:
* Right-click in the Action column and choose Set.
* Select New > Authenticate.
* Select the authentication mode and realm. (See ProxySG Authentication Modes.)
* Close the dialogs.
4. Create an Admin Access layer (Policy > Add Admin Access Layer).
5. In the Admin Access layer, define who is allowed to access the ProxySG:

* Right-click in the Source column and choose Set.
* Select New.
* Select the entity (for example, Client IP address/subnet, User, Group) and configure the specifics.
* Close the dialogs.

6. Specify the type of administrator read/write access:

* Right-click the Action column and select Allow Read-only Access or Allow Read/Write Access.

7. By default, the policy applies to any service (HTTP/HTTPS in the Management Console and SSL in the CLI). If you want to control access to just the MC or just the CLI:

* Right-click in the Service column and choose Set.
* Select New > Service Name.
* Select the service you want the rule to apply to (HTTP-Console, HTTPS-Console, or SSH-Console).
* Close the dialogs.
8. Install the policy.

How to debug IKE encryption problems

If the IKE tunnel cannot be established have a look in the FireWall-1 logviewer. 
If the logviewer is not helpful, use the advanced IKE debugging option in FireWall-1:

Set the appropriate debug variable:

setenv FWISAKMP_DEBUG=1 (for FireWall-1 4.0)
setenv FWIKE_DEBUG=1 (for FireWall-1 4.1)

(On NT firewalls, use 'set' instead of setenv)

Rerun the FireWall-1 daemon (do: 'fwstop' and 'fwstart'). 

All subsequent IKE negotiations will be dumped in the file ISAKMP.log in FireWall-1 4.0 
or IKE.elg in FireWall-1 4.1 (both in $FWDIR/log.

An advanced IKE user can use this file to help detect IKE problems. This file should be sent whenever contacting Check Point

How to redirect logs to a different partition

For logging on Windows :
Regedit
go to HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\FW1\5.0
create FWLOGDIR and put the full path to the log you want to go to

For logging on Unix :
ln -s /path/to/new/logdir $FWDIR/log
If you're talking about Windows NT then there is a registry hack.

enter the HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\FW1\4.1 path and add a new
string value form the edit-->new menu. name it FWLOGDIR.
add the directory name that you wsih to log to, and create the directory.
then bounce the firewall (fwstop/fwstart).

MS Office 2007 deploy by the group policy on window server 2003

You can use Group Policy to assign computer startup scripts to deploy the 2007 Microsoft Office system. You can use a script written in any language that is supported by your client computers. Windows Script Host-supported languages, such as VBScript and Jscript, and command files are the most common.

Group Policy Scripts Extensions

The Group Policy infrastructure includes a Scripts extension that consists of:

·         A Microsoft Management Console (MMC) server-side extension of the Group Policy Object Editor MMC snap-in that is used for administering and configuring scripts. You can use the scripts extension to specify scripts policy settings in a GPO and then link the GPO to the site, domain, or organizational unit to which you want to assign the scripts.

·         A client-side extension, which is a DLL on the client computer that interacts with the Group Policy infrastructure and implements Group Policy scripts on the client computer. A separate process called Userinit.exe runs the scripts.

The GPO Editor snap-in includes two extensions for script deployment:

·         Scripts (Startup/Shutdown). Use this extension to specify scripts that run when the computer starts up or shuts down. These scripts run as Local System. Scripts (Startup/Shutdown) is located under the Computer Configuration\Windows Settings node of the GPO Editor.

·         Scripts (Logon/Logoff). Use this extension to specify scripts that run when the user logs on or logs off the computer. These scripts run as User, not as Administrator. Scripts (Logon/Logoff) is located under the User Configuration\Windows Settings node of the GPO Editor.

For more information about Group Policy Scripts extensions, see the Scripts Extension Technical Reference. For information about Windows Script Host, see Windows Script Host.

Advantages

If you have already deployed Active Directory and Group Policy in your organization, using computer startup scripts to deploy Office 2007 provides the following benefits:

·         Scripts or batch files for Office 2007 client deployment are relatively simple to create.

·         Administrators can use a command line to point to their Office Setup customization file (.MSP file) for advanced feature and settings customization. Setup customization files are created when administrators use the Office Customization Tool (OCT) to customize an installation of the 2007 Microsoft Office system. For more information about .MSP files, see Office Customization Tool in the 2007 Office system.

·         Administrators can use a command line to point to the Config.xml file for adding languages and other customizations. Modifying the Config.xml file is one of the ways in which administrators can make changes to the 2007 Office system installation. For more information about Config.xml files, see Config.xml file in the 2007 Office system, and the Applying customizations to the Office installation and Modifying the Config.xml File OptionState element sections in Use Group Policy Software Installation to deploy the 2007 Office system.

·         The source files for product installation can be stored on a network share or on each local computer, if the bits are pre-staged.

·         The product installation occurs in the system context, before the users log on. Active Directory handles the elevation of privileges required for application installation.

·         Users can add or remove product features by using Add or Remove Programs in Control Panel.

·         Administrators can use a similar scripting process to apply security updates and service packs for each computer in the domain or organizational unit.

·         Microsoft Windows Server Update Services 3.0 (WSUS 3.0) can be used to manage and deliver product updates. For information about WSUS, see Microsoft Windows Server Update Services 3.0 Overview and Step-by-Step Guide to Getting Started with Microsoft Windows Server Update Services 3.0 on the Microsoft TechNet Web site.

Considerations

Be sure to consider the following issues:

·         The product installation is not managed in the same way as Group Policy Software Installation.

·         Group Policy invokes the script and has limited awareness of the installation state thereafter. If the GPO that contains the script is removed (goes out of scope), Office is not removed.

·         Deploying with scripts requires basic knowledge of valid command-line options for Setup.exe in 2007 Office applications. For information about command-line options, see Setup command-line options for the 2007 Office system .

·         Product uninstalls and reinstalls for multiple computers have to be done by using a command line script or batch file.

·         Automatic product reinstall after a user-initiated uninstall does not work in the same way as when Group Policy Software Installation is used. With Group Policy Software Installation, if a user removes a user-assigned application by using Add or Remove Programs in Control Panel, the Group Policy Software installation extension automatically reapplies the advertisement information after the user logs on or the computer restarts. The software is reinstalled the next time the user selects it or tries to open a file with an associated file name extension.

·         Determining exactly which updates and service packs were applied for each client computer may be difficult.

Group Policy provides the ability to affect configurations across hundreds and even thousands of computers in an organization. Therefore, it is critical that you rigorously test all new Group Policy configurations or deployments in a non-production environment before you move them into your production environment. For detailed information about staging Group Policy deployments, see Staging Group Policy     Deployments(http://technet2.microsoft.com/WindowsServer/en/library/e5288e42-62b8-4f9e-a665-95b6e02389a31033.mspx in the Designing a Managed Environment book of the Microsoft Windows Server 2003 Deployment Kit.

By default, the system lets combined sets of scripts run for up to 600 seconds (10 minutes) only. Administrators can use a policy setting to adjust this interval to ensure the startup script completes running. The Maximum wait time for Group Policy scripts policy setting specifies how long the system waits for scripts applied by Group Policy to run. This setting limits the total time allowed for all logon, startup, and shutdown scripts applied by Group Policy to finish running. As with any Group Policy deployment, you must fully test your startup scripts in a staging environment before deploying them to your production environment. Testing will help you determine the value to use for the Maximum wait time for Group Policy scripts policy for your particular network environment. Setting this value too low may cause the install to terminate prematurely. There are factors that may affect this value, such as network speed, client computer hardware, and other scripts running on the client computer. By fully testing this policy setting you can determine the appropriate value to use for your specific environment.

The Maximum wait time for Group Policy scripts policy setting is available in the Computer Configuration\Administrative Templates\System\Scripts folder in Group Policy Object Editor. For information about configuring this policy setting, see Specifying maximum time for startup scripts to run.

Startup scripts

Startup scripts run as Local System and have the full rights required to run as Local System.

If you haven’t already installed GPMC, you can get it at Download Group Policy Management Console (GPMC). For more information and procedures for using GPMC and working with GPOs, see Group Policy Management Tools and Using Group Policy Management Console and Group Policy Object Editor sections in Enforce settings by using Group Policy in the 2007 Office system.

You must be logged on as a member of the Domain Administrators security group, the Enterprise Administrators security group, or the Group Policy Creator Owners security group to complete these procedures.

Sample script

The following sample .bat script illustrates how to perform the following tasks:

·         Run Microsoft Office Setup.exe if the product is not already installed.

·         Log error or success to a centralized log file.

This .bat script example provides flexibility and can be customized for other Office products. The following requirements apply to the sample script:

·         The target computer must be running Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008.

·         Microsoft Windows Installer (MSI) 3.1 is required if you use a customization patch

·         A Read-only network share containing the Office source files

·         A Read-write network share for storing centralized log files

·         A custom Config.xml file or customization patch to direct Setup.exe to run quietly. For instructions for modifying the Display element in the Config.xml file, see.

REM *********************************************************************

REM Environment customization begins here. Modify variables below.

REM *********************************************************************

REM Get ProductName from the Office product's core Setup.xml file.

set ProductName=Enterprise

REM Set DeployServer to a network-accessible location containing the Office source files.

set DeployServer=\\server\share\Office12

REM Set ConfigFile to the configuration file to be used for deployment REM (required)

set ConfigFile=\\server\share\Office12\Enterprise.WW\config.xml

REM Set LogLocation to a central directory to collect log files.

set LogLocation=\\server\share\Office12Logs

REM *********************************************************************

REM Deployment code begins here. Do not modify anything below this line.

REM *********************************************************************

IF NOT "%ProgramFiles(x86)%"=="" SET WOW6432NODE=WOW6432NODE\

reg query HKEY_LOCAL_MACHINE\SOFTWARE\%WOW6432NODE%Microsoft\Windows\CurrentVersion\Uninstall\%ProductName%

if %errorlevel%==1 (goto DeployOffice) else (goto End)

REM If 1 returned, the product was not found. Run setup here.

:DeployOffice

start /wait %DeployServer%\setup.exe /config %ConfigFile%

echo %date% %time% Setup ended with error code %errorlevel%. >> %LogLocation%\%computername%.txt

REM If 0 or other was returned, the product was found or another error occurred. Do nothing.

:End

Endlocal

In this example, script logging information is written to computername.txt file. A return code of 0 in the log file indicates that the installation completed successfully. A return code of 3010 indicates that a reboot is required. For more information about other error codes for Windows Installer processes for Office products, on the Microsoft Knowledge Base Web site.

Specifying Silent Install Options in the Config.xml file

1.       Open the Config.xml file in a text editor tool, such as Notepad.

2.       Locate the line that contains the Display element, as shown in the following example:

3.       Modify the Display element entry to specify silent install options. For example if you want to specify that no user interface or modal dialog boxes are displayed, use the following syntax:

4.       Save the Config.xml file in the same folder that contained this file before you edited it.

Setting up scripts on the domain controller

Copy the script and dependent files to the Netlogon shared folder or another shared folder on the domain controller from which you want the script to run.

The target computer account needs Read permission to the Office source files location, and Read and Write permissions to the log file location. The log file can be stored on the local computer.

Assigning computer startup scripts

1.       Click Start, click Control Panel, click Administrative Tools, and click Group Policy Management.

2.       In the console tree, double-click Group Policy Objects in the forest and domain that contains the Group Policy object (GPO) that you want to edit. This is located in Forest name/Domains/Domain name/Group Policy Objects.

3.       Right-click the GPO you want to use to assign scripts and click Edit. This opens the Group Policy Object Editor console.

4.       In Group Policy Object Editor, in the console tree, click Scripts (Startup/Shutdown). This is located in the Computer Configuration\Windows Settings node.

5.       In the details pane, double-click Startup.

6.       In the Startup Properties dialog box, click Add.

7.       In the Add a Script dialog box, do the following:

In Script Name, type the path to the script, or click Browse to search for the script file in the Netlogon shared folder on the domain controller.

In Script Parameters, type the parameters you want to use as you would type them on the command line. For example, if your script included parameters called //logo (display banner) and //I (interactive mode), type: //logo //I.

8.       In the Startup Properties dialog box, specify the options you want to use. The following options are available:

Startup Scripts for Group Policy object. Lists all the scripts that are currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed in the order that you specify. To move a script up in the list, select the script and click Up. To move a script down in the list, select the script and click Down.

Add. Opens the Add a Script dialog box, where you can specify additional scripts to use.

Edit. Opens the Edit Script dialog box, where you can modify script information, such as name and parameters.

Remove. Removes the selected script from the Startup Scripts list.

Show Files. Displays the script files that are stored in the selected Group Policy object.

Specifying maximum time for startup scripts to run

Make sure you fully test startup scripts in a staging, non-production environment before you deploy them to your production environment.

1.       Click Start, click Control Panel, click Administrative Tools, and click Group Policy Management.

2.       In the console tree, double-click Group Policy Objects in the forest and domain that contains the Group Policy object (GPO) that you want to edit. This is located in Forest name/Domains/Domain name/Group Policy Objects.

3.       Right-click the GPO you want to use to assign scripts and click Edit. This opens the Group Policy Object Editor console.

4.       In Group Policy Object Editor, in the console tree, navigate to Computer Configuration\Administrative Templates\System\Scripts.

5.       On the details pane (left side of the console), double-click the Maximum wait time for Group Policy scripts policy setting, click Enabled, enter the value you want to use in the Seconds scroll-down box, and then click OK.

remotely install software in Windows Server 2003 and in Windows Server 2008 by using Froup Policy

• Assigning Software
  You can assign a program distribution to users or computers. If you assign the program to a user, it is installed when the user logs on to the computer. When the user first runs the program, the installation is finalized. If you assign the program to a computer, it is installed when the computer starts, and it is available to all users who log on to the computer. When a user first runs the program, the installation is finalized.
• Publishing Software
  You can publish a program distribution to users. When the user logs on to the computer, the published program is displayed in the Add or Remove Programs dialog box, and it can be installed from there.

Note Windows Server 2003 Group Policy automated-program installation requires client computers that are running Microsoft Windows 2000 or later.

Create a Distribution Point

To publish or assign a computer program, you must create a distribution point on the publishing server:

1. Log on to the server computer as an administrator.
2. Create a shared network folder where you will put the Microsoft Windows Installer package (.msi file) that you want to distribute.
3. Set permissions on the share to allow access to the distribution package.
4. Copy or install the package to the distribution point. For example, to distribute Microsoft Office XP, run the administrative installation (setup.exe /a) to copy the files to the distribution point.

Create a Group Policy Object

To create a Group Policy object (GPO) to use to distribute the software package:

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. In the console tree, right-click your domain, and then click Properties.
3. Click the Group Policy tab, and then click New.
4. Type a name for this new policy (for example, Office XP distribution), and then press ENTER.
5. Click Properties, and then click the Security tab.
6. Click to clear the Apply Group Policy check box for the security groups that you want to prevent from having this policy applied.
7. Click to select the Apply Group Policy check box for the groups that you want this policy to apply to.
8. When you are finished, click OK.

Assign a Package

To assign a program to computers that are running Windows Server 2003, Windows 2000, or Microsoft Windows XP Professional, or to users who are logging on to one of these workstations:

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. In the console tree, right-click your domain, and then click Properties.
3. Click the Group Policy tab, select the group policy object that you want, and then click Edit.
4. Under Computer Configuration, expand Software Settings.
5. Right-click Software installation, point to New, and then click Package.
6. In the Open dialog box, type the full Universal Naming Convention (UNC) path of the shared installer package that you want. For example, \\file server\share\file name.msi.
   
   Important Do not use the Browse button to access the location. Make sure that you use the UNC path to the shared installer package.
7. Click Open.
8. Click Assigned, and then click OK. The package is listed in the right pane of the Group Policy window.
9. Close the Group Policy snap-in, click OK, and then quit the Active Directory Users and Computers snap-in.
10. When the client computer starts, the managed software package is automatically installed.

Publish a Package

To publish a package to computer users and make it available for installation from the Add or Remove Programs tool in Control Panel:

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. In the console tree, right-click your domain, and then click Properties.
3. Click the Group Policy tab, click the group policy object that you want, and then click Edit.
4. Under User Configuration, expand Software Settings.
5. Right-click Software installation, point to New, and then click Package.
6. In the Open dialog box, type the full UNC path of the shared installer package that you want. For example, \\file server\share\file name.msi.
   
   Important Do not use the Browse button to access the location. Make sure that you use the UNC path to the shared installer package.
7. Click Open.
8. Click Publish, and then click OK.
9. The package is listed in the right pane of the Group Policy window.
10. Close the Group Policy snap-in, click OK, and then quit the Active Directory Users and Computers snap-in.
11. Test the package:
    
    Note Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see your product documentation to complete these steps.

1. Log on to a workstation that is running Windows 2000 Professional or Windows XP Professional by using an account that you published the package to.
2. In Windows XP, click Start, and then click Control Panel.
3. Double-click Add or Remove Programs, and then click Add New Programs.
4. In the Add programs from your network list, click the program that you published, and then click Add. The program is installed.
5. Click OK, and then click Close.

Redeploy a Package

In some cases you may want to redeploy a software package. For example, if you upgrade or modify the package. To redeploy a package:

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. In the console tree, right-click your domain, and then click Properties.
3. Click the Group Policy tab, click the Group Policy object that you used to deploy the package, and then click Edit.
4. Expand the Software Settings container that contains the software installation item that you used to deploy the package.
5. Click the software installation container that contains the package.
6. In the right pane of the Group Policy window, right-click the program, point to All Tasks, and then click Redeploy application. You will receive the following message:

Redeploying this application will reinstall the application everywhere it is already installed. Do you want to continue?

7. Click Yes.
8. Quit the Group Policy snap-in, click OK, and then quit the Active Directory Users and Computers snap-in.

Remove a Package

To remove a published or assigned package:

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. In the console tree, right-click your domain, and then click Properties.
3. Click the Group Policy tab, click the Group Policy object that you used to deploy the package, and then click Edit.
4. Expand the Software Settings container that contains the software installation item that you used to deploy the package.
5. Click the software installation container that contains the package.
6. In the right pane of the Group Policy window, right-click the program, point to All Tasks, and then click Remove.
7. Do one of the following:
• Click Immediately uninstall the software from users and computers, and then click OK.
• Click Allow users to continue to use the software but prevent new installations, and then click OK.
8. Quit the Group Policy snap-in, click OK, and then quit the Active Directory Users and Computers snap-in.

Troubleshoot

Published Packages Are Displayed on a Client Computer After You Use a Group Policy to Remove Them

This situation can occur when a user has installed the program but has not used it. When the user first starts the published program, the installation is finalized. Group Policy then removes the program.