How to configure WSUS 3.0 SP2 in window server 2003

Step 1: Confirm WSUS 3.0 SP2 installation requirements

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Standard

Before you install or upgrade to Windows Server Upgrade Services 3.0 Service Pack 2 (WSUS 3.0 SP2), confirm that both the server and the client computers meet the minimum system requirements and confirm that you have the necessary permissions to complete the installation.

Server hardware and software requirements for installing WSUS 3.0 SP2

1. Confirm that the server meets the minimum system requirements for hardware, operating system, and other required software. Detailed system requirements are listed in the WSUS 3.0 SP2 System Requirements section of the WSUS 3.0 SP2 Deployment Guide. If you are using Server Manager to install the WSUS 3.0 SP2 Server, you can confirm that you meet the software requirements by following the steps in the Preparing to Install WSUS 3.0 SP2 section.
2. If you install roles or software updates that require you to restart the server when installation is complete, then restart the server before you install WSUS 3.0 SP2.

Client software requirements

Automatic Updates is the client of WSUS 3.0 SP2. Automatic Updates has no hardware requirements other than being connected to the network.

1. Confirm that computer on which you are installing Automatic Updates meets the WSUS 3.0 SP2 system requirements for Client computers. Detailed system requirements are listed in the WSUS 3.0 SP2 System Requirements section of the WSUS 3.0 SP2 Deployment Guide.
2. If you install software updates that require you to restart the computer, restart it before you install WSUS 3.0 SP2.

Permissions

The following permissions are required for the specified users and directories:

1. The NT Authority\Network Service account must have Full Control permission for the following folders so that the WSUS Administration snap-in displays correctly:
• %windir%\Microsoft .NET\Framework\v2.0.50727\Temporary ASP.NET Files
• %windir%\Temp
2. Confirm that the account that you plan to use to install WSUS 3.0 SP2 is a member of the Local Administrators group.

Preparing to install WSUS 3.0 SP2

You can install the WSUS server software using two different methods: through the user interface (Server Manager) or in unattended mode (WSUSSetup.exe). You must install WSUS on at least one server.

For more information about installing WSUS, see the Install the WSUS 3.0 SP2 Server section of the WSUS 3.0 SP2 Deployment Guide.

To prepare to install the WSUS 3.0 SP2 Server by using Server Manager

1. Log on to the server on which you plan to install WSUS 3.0 SP2 by using an account that is a member of the Local Administrators group.
2. Click Start, point to Administrative Tools, and then click Server Manager.
3. In the right side pane of the Server Manager window, in the Roles Summary section, click Add Roles.
4. If the Before You Begin page appears, click Next.
5. On the Select Server Roles page, confirm that Application Server and Web Server (IIS) are selected. If they have been selected, use the remainder of this step to confirm that the required role services are selected. Otherwise, install Application Server and Web Server (IIS) as follows.
1. On the Select Server Roles page, select Application Server and Web Server (IIS). Click Next.
2. If you are installing Application Role Services, on the Application Server page, click Next. On the Application Server Role Services page, accept the default settings, and then click Next.
3. If you are installing Web Server IIS, on the Web Server (IIS) page, click Next. On the Web Server (IIS) Role Services page, in addition to the default settings, select ASP.NET, Windows Authentication, Dynamic Content Compression, and IIS 6 Management Compatibility. If the Add Roles Wizard window appears, click Add Required Role Services. Click Next.
4. On the Confirm Installation Selections page, click Install.
5. On the Installation Results page, confirm that an “Installation succeeded” message appears for the role services that you installed in this step, and then click Close.

Step 2: Install WSUS Server or Administration Console

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Standard

In Step 1: Confirm WSUS 3.0 SP2 installation requirements you confirmed that the server meets the minimum system requirements and that the necessary account permissions were granted You are ready to install WSUS 3.0 SP2. Start the installation of WSUS by using the applicable procedure for your operating system and kind of installation (by using either Server Manager or the WSUSSetup.exe file).

If you are using Server Manager

To start the installation of WSUSby using Server Manager

1. Log on to the server on which you plan to install WSUS 3.0 SP2 by using an account that is a member of the local Administrators group.
2. Click Start, point to Administrative Tools, and then click Server Manager.
3. In the right side pane of the Server Manager window, in the Roles Summary section, click Add Roles.
4. If the Before You Begin page appears, click Next.
5. On the Select Server Roles page, select Windows Server Update Services.
6. On the Windows Server Update Services page, click Next.
7. On the Confirm Installation Selections page, click Install.
8. When the WSUS Setup Wizard starts, skip the next section and see Using the WSUS Setup Wizard.

If you are using the WSUSSetup.exe file

To start the installation of WSUS or the Administration Console by using the WSUSSetup.exe file

1. Log on to the server on which you plan to install WSUS 3.0 SP2 by using an account that is a member of the Local Administrators group.
2. Double-click the WSUSSetup.exe installer file.
3. When the WSUS Setup Wizard starts, see Using the WSUS Setup Wizard.

Using the WSUS Setup Wizard

The WSUS Setup Wizard is launched from Server Manager or from the WSUSSetup.exe file.

To continue installing WSUS

1. On the Welcome page of the Windows Server Update Services 3.0 Setup Wizard, click Next.
2. On the Installation Mode Selection page, select Full server installation including Administration Console if you want to install the WSUS server on this computer, or Administration Console only if you want to install the administration console only.
3. On the License Agreement page, read the terms of the license agreement, click I accept the terms of the License agreement, and then click Next.
4. You can specify where clients get updates on the Select Update Source page of the installation wizard. By default, the Store updates locally check box is selected and updates will be stored on the WSUS server in the location that you specify. If you clear the Store updates locally check box, client computers obtain approved updates by connecting to Microsoft Update. Make your selection, and then click Next.
5. 
6. 
   

5. On the Database Options page, select the software that will be used to manage the WSUS database. By default, the installation wizard offers to install Windows® Internal Database.

If you do not want to use Windows Internal Database, provide an instance of Microsoft SQL Server for WSUS to use by selecting Use an existing database on this server or Use an existing database server on a remote computer. Type the instance name in the applicable box. The instance name should appear as <serverName>\<instanceName>, where serverName is the name of the server and instanceName is the name of the SQL instance. Make your selection, and then click Next.

6. If you have opted to connect to a SQL Server, on the Connecting to SQL Server Instance page, WSUS will try to connect to the specified instance of SQL Server. When it has connected successfully, click Next to continue.
7. On the Web Site Selection page, specify the Web site that WSUS will use. If you want to use the default Web site on port 80, select Use the existing IIS Default Web site. If you already have a Web site on port 80, you can create an alternate site on port 8530 or 8531 by selecting Create a Windows Server Update Services 3.0 SP2 Web site. Click Next.

8. On the Ready to Install Windows Server Update Services page, review the selections, and then click Next.
9. The final page of the installation wizard will let you know if the WSUS installation completed successfully. After you click Finish the configuration wizard will start.

Step 3: Configure the network connections

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Standard

After Step 2: Install WSUS Server or Administration Console, where you installed WSUS 3.0 SP2, the configuration wizard will launch automatically. You can also run the wizard later through the Options page of the WSUS Administration Console.

Before you start the configuration process, be sure that you know the answers to the following questions:

1. Is the server's firewall configured to allow clients to access the server?
2. Can this computer connect to the upstream server (such as Microsoft Update)?
3. Do you have the name of the proxy server and the user credentials for the proxy server, if you need them?

By default, WSUS 3.0 SP2 is configured to use Microsoft Update as the location from which to obtain updates. If you have a proxy server on the network, you can configure WSUS to use the proxy server. If there is a corporate firewall between WSUS and the Internet, you might have to configure the firewall to ensure that WSUS can obtain updates.

Note

Although Internet connectivity is required to download updates from Microsoft Update, WSUS offers you the ability to import updates onto networks that are not connected to the Internet.

Step 3 contains the following procedures:

• Configure your firewall.
• Specify the way this server will obtain updates (either from Microsoft Update or from another WSUS server).
• Configure proxy server settings, so that WSUS can obtain updates.

To configure your firewall

• If there is a corporate firewall between WSUS and the Internet, you might have to configure that firewall to ensure WSUS can obtain updates. To obtain updates from Microsoft Update, the WSUS server uses port 80 for HTTP protocol and port 443 for HTTPS protocol. This is not configurable.
• There are still some firewalls in the market which require access rules to be configured using IP addresses rather than DNS names. Due technical and security reason we don’t release the IP address range and therefore our official recommendation is to create exclusion list using the names that are specified in the KB 896226. If your firewall does not support exception list with DNS name the other option that you have is to use two WSUS servers. Place one server inside the corporate firewall and place the other server in the perimeter network. Configure the firewall to allow the server located in the perimeter network to communicate with the internal WSUS server. As the perimeter WSUS server can receive updates from the Windows Update domains, the internal WSUS server can receive updates from the perimeter WSUS server, and the client computers (and any other WSUS servers) can receive updates from the internal server.
• If your organization does not allow the required ports and protocols to be open to all Internet addresses, you can restrict access to specific domains. For more information, see the following Microsoft Support articles:
• Article ID: 896226
• Article ID: 885819

Note

These instructions about how to configure the firewall are meant for a corporate firewall positioned between WSUS and the Internet. Because WSUS initiates all of its network traffic, you do not have to configure Windows Firewall on the WSUS server.

Although the connection between Microsoft Update and WSUS requires ports 80 and 443 to be open, you can configure multiple WSUS servers to synchronize with a custom port.

The next two procedures assume that you are using the Configuration Wizard. In a later section in this step, you will learn how to start the WSUS Administration snap-in and configure the server through the Options page.

To specify the way this server will obtain updates

1. From the configuration wizard, after joining the Microsoft Improvement Program, click Next to select the upstream server.
2. If you choose to synchronize from Microsoft Update, you are finished with the Options page. Click Next, or select Specify Proxy Server from the navigation pane.
3. If you choose to synchronize from another WSUS server, specify the server name and the port on which this server will communicate with the upstream server.
4. To use SSL, select the Use SSL when synchronizing update information check box. In that case the servers will use port 443 for synchronization. (Make sure that both this server and the upstream server support SSL.)
5. If this is a replica server, select the This is a replica of the upstream server check box.
6. At this point, you are finished with upstream server configuration. Click Next, or select Specify proxy server from the left navigation pane.

To configure proxy server settings

1. On the Specify Proxy Server page of the configuration wizard, select the Use a proxy server when synchronizing check box, and then type the proxy server name and port number (port 80 by default) in the corresponding boxes.
2. If you want to connect to the proxy server by using specific user credentials, select the Use user credentials to connect to the proxy server check box, and then type the user name, domain, and password of the user in the corresponding boxes. If you want to enable basic authentication for the user connecting to the proxy server, select the Allow basic authentication (password is sent in cleartext) check box.
3. At this point, you are finished with proxy server configuration. Click Next to go to the next page, where you can start to set up the synchronization process.

The following two procedures assume that you are using the WSUS Administration snap-in for configuration. These two procedures show how to start the WSUS Administration snap-in and configure the server from the Options page

.

To start the WSUS Administration Console

• To start the WSUS Administration Console, click Start, point to All Programs, point to Administrative Tools, and then click Windows Server Update Services 3.0.

Note

In order to use all the features of the console, log on as a member of either the WSUS Administrators or the Local Administrators security groups on the server on which WSUS is installed. Members of the WSUS Reporters security group have read-only access to the console.

To specify an update source and proxy server

1. On the WSUS console, click Options in the left pane under the name of this server, and then click Update Source and Proxy Server in the middle pane.

A dialog box will be displayed with Update Source and Proxy Server tabs.

2. In the Update Source tab, select the location from which this server will obtain updates. If you choose to synchronize from Microsoft Update (the default), you are finished with this wizard page.
3. If you choose to synchronize from another WSUS server, you have to specify the port on which the servers will communicate (the default is port 80). If you select a different port, you should ensure that both servers can use that port.
4. You may also specify whether to use SSL when synchronizing from the upstream WSUS server. In that case, the servers will use port 443 to synchronize from the upstream server.
5. If this server is a replica of the second WSUS server, select the This is a replica of the upstream server check box. In this case all updates must be approved on the upstream WSUS server only.
6. In the Proxy server tab, select the Use a proxy server when synchronizing check box, and then type the proxy server name and port number (port 80 by default) in the corresponding boxes.
7. If you want to connect to the proxy server by using specific user credentials, select the Use user credentials to connect to the proxy server check box, and then type the user name, domain, and password of the user in the corresponding boxes. If you want to enable basic authentication for the user connecting to the proxy server, select the Allow basic authentication (password in cleartext) check box.
8. Click OK to save these settings.

Step 4: Configure updates and synchronization

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Standard

This section describes how to configure a set of updates that you want to download by using WSUS 3.0 SP2.

Step 4 Procedures

You can do these procedures by using either the WSUS Configuration Wizard or the WSUS Administration Console.

1. Save and download information about your upstream server and proxy server.
2. Choose the language of the updates.
3. Select the products for which you want to receive updates.
4. Choose the classifications of updates.
5. Specify the synchronization schedule for this server.

After you configure the network connection, you can download updates by synchronizing the WSUS server. Synchronization begins when the WSUS server contacts Microsoft Update. After the WSUS makes contact, WSUS determines whether any new updates have been made available since the last time you synchronized. When you synchronize the WSUS server for the first time, all the updates are available and are ready for your approval for installation. The initial synchronization may take a long time.

The procedures in this section describe synchronizing with the default settings. WSUS 3.0 SP2 also includes options that enable you to minimize bandwidth use during synchronization.

If you are using the WSUS Configuration Wizard

In Step 3: Configure the network connections, you completed configuration of the upstream server and the proxy server. This next set of procedures starts on the Connect to Upstream Server page of that configuration wizard.

To save and download your upstream server and proxy information

1. On the Connect to Upstream Server page of the configuration wizard, click the Start Connecting button. This both saves and uploads your settings and collects information about available updates.
2. While the connection is being made, the Stop Connecting button will be available. If there are problems with the connection, click Stop Connecting, fix the problems, and restart the connection.
3. After the download has completed successfully, click Next.

To choose update languages

1. The Choose Languages page lets you receive updates from all languages or from a subset of languages. Selecting a subset of languages will save disk space, but it is important to choose all of the languages that will be needed by all the clients of this WSUS server.

If you choose to get updates only for specific languages, select Download updates only in these languages, and select the languages for which you want updates.

2. Click Next.

To choose update products

1. The Choose Products page lets you specify the products for which you want updates. Select product categories, such as Windows, or specific products, such as Windows Server 2008. Selecting a product category will cause all the products in that category to be selected.
2. Click Next.

To choose update classifications

1. The Choose Classifications page allows you to specify the update classifications you want to obtain. Choose all the classifications or a subset of them.
2. Click Next

To configure the synchronization schedule

1. On the Set Sync Schedule page, you choose whether to perform synchronization manually or automatically.

If you choose Synchronize manually, you must start the synchronization process from the WSUS Administration Console.

If you choose Synchronize automatically, the WSUS server will synchronize at set intervals. Set the time of the First synchronization and specify the number of Synchronizations per day that you want this server to perform. For example, if you specify that there should be four synchronizations per day, starting at 3:00 A.M., synchronizations will occur at 3:00 A.M., 9:00 A.M., 3:00 P.M., and 9:00 P.M.

2. Click Next.
3. On the Finished page, you can start the WSUS Administration Console by leaving the Launch the Windows Server Update Services Administrations snap-in check box selected, and you can start the first synchronization by leaving the Begin initial synchronization check box selected.
4. Click Finish.

Important

You cannot save configuration changes that are made while the server is synchronizing. Wait until synchronization is finished and then make your changes.

If You Are Using the WSUS Administration Console

The following procedures explain how to perform the configuration steps by using the WSUS Administration Console.

To choose products and update classifications

1. In the Options panel, click Products and Classifications. A dialog box appears with Products and Classifications tabs.
2. In the Products tab, select the product category or specific products for which you want this server to receive updates, or else select All Products.
3. In the Classifications tab, select the update classifications you want, or else select All Classifications.
4. Click OK to save your selections.

To choose update files and languages

1. In the Options panel, click Update Files and Languages. A dialog box appears with Update Files and Update Languages tabs.
2. In the Update Files tab, choose whether to Store update files locally on this server or to have all client computers install from Microsoft Update. If you decide to store update files on this server, you also decide whether to download only those updates that are approved or to download express installation files.
3. In the Update Languages tab, if you are storing update files locally, you choose to Download updates for all languages (the default), or to Download updates only in the specified languages. If this WSUS server has downstream servers, they will receive updates only in the languages specified by the upstream server.
4. Click OK to save these settings.

To synchronize the WSUS server

1. In the Options panel, click Synchronization Schedule.
2. In the Synchronization Schedule tab, you choose whether to perform synchronization manually or automatically.

If you choose Synchronize manually, you will have to start the synchronization process from the WSUS Administration Console.

If you choose Synchronize automatically, the WSUS server will synchronize at set intervals. Set the time of the First synchronization and specify the number of Synchronizations per day that you want this server to perform. For example, if you specify that there should be four synchronizations per day, starting at 3:00 A.M., synchronizations will occur at 3:00 A.M., 9:00 A.M., 3:00 P.M., and 9:00 P.M.

3. Click OK to save your selections.
4. In the navigation pane of the WSUS Administration Console, select Synchronizations.
5. Right-click or move to the Actions pane on the right side, and then click Synchronize Now.

If you do not see the Actions pane on the right side of the console, on the console toolbar click View, click Customize, and ensure that the Action pane check box is selected.

6. After the synchronization is complete, in the left panel, click Updates to view the list of updates.

Step 5: Configure client updates

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Standard

In WSUS 3.0 SP2, the WSUS Setup automatically configures IIS to distribute the latest version of Automatic Updates to each client computer that contacts the WSUS server.

The best way to configure Automatic Updates depends on the network environment. In an environment that uses Active Directory directory service, you can use an existing domain–based Group Policy Object (GPO) or create a new GPO. In an environment without Active Directory, use the Local GPO. In this step, you will configure Automatic Updates and then point the client computers to the WSUS server.

The following procedures assume that your network runs Active Directory. These procedures also assume that you are familiar with Group Policy and use it to manage the network.

For more information about Group Policy, see the Group Policy Resources on Windows Server Tech Center.

Step 5 Procedures

In Step 4: Configure updates and synchronization, you completed configuration of the updates that you want to download. Use this set of procedures to configure automatic updates for client computers.

1. Configure Automatic Updates in Group Policy.
2. Point a client computer to the WSUS server.
3. Manually start detection by the WSUS server.

Perform the first two procedures on the domain–based GPO of your choice, and the third procedure at a command prompt on the client computer.

To configure Automatic Updates

1. In the Group Policy Management Console (GPMC), browse to the GPO on which you want to configure WSUS, and then click Edit.
2. In the GPMC, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
3. In the details pane, double-click Configure Automatic Updates.
4. Click Enabled, and then click one of the following options:
• Notify for download and notify for install. This option notifies a logged-on administrative user before the download and before you install the updates.
• Auto download and notify for install. This option automatically begins downloading updates and then notifies a logged-on administrative user before installing the updates.
• Auto download and schedule the install. This option automatically begins downloading updates and then installs the updates on the day and time that you specify.
• Allow local admin to choose setting. This option lets local administrators to use Automatic Updates in Control Panel to select a configuration option. For example, they can choose their own scheduled installation time. Local administrators cannot disable Automatic Updates.
5. Click OK.

To point the client computers to the WSUS server

1. In the Windows Update details pane, double-click Specify intranet Microsoft update service location.
2. Click Enabled, and type the HTTP URL of the same WSUS server in the Set the intranet update service for detecting updates box and in the Set the intranet statistics server box. For example, type http://servername in both boxes, and then click OK.

Note

If you are using the Local GPO to point the computer to WSUS, this setting takes effect immediately, and this computer appears in the WSUS Administrative Console after a short time. You can speed up this process by manually initiating a detection cycle.

After you set up a client computer, it will take several minutes before the computer appears on the Computers page in the WSUS Administration Console. For client computers configured with a domain-based Group Policy, it can take about 20 minutes after Group Policy refreshes (that is, applies any new policy settings to the client computer). By default, Group Policy updates in the background every 90 minutes, with a random offset of 0–30 minutes. If you want to update Group Policy sooner, you can go to a command prompt on the client computer and type gpupdate /force.

For client computers configured by using the Local GPO, Group Policy is applied immediately, and the update takes about 20 minutes.

If you begin detection manually, you do not have to wait 20 minutes for the client computer to contact WSUS.

To manually start detection by the WSUS server

1. On the client computer, click Start, and then click Run.
2. Type cmd in the Open box, and then click OK.
3. At the command prompt, type wuauclt.exe /detectnow. This command-line option instructs Automatic Updates to contact the WSUS server immediately.

Step 6: Configure computer groups

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Standard

Computer groups are an important part of WSUS 3.0 SP2 deployments. Computer groups permit you to test updates and target updates to specific computers. There are two default computer groups: All Computers and Unassigned Computers. By default, when each client computer first contacts the WSUS Server, the server adds that client computer to both of these groups.

You can create as many custom computer groups as you need to manage updates in your organization. As a best practice, create at least one computer group to test updates before you deploy them to other computers in your organization.

Step 6 Procedures

1. Create a test computer group.
2. Move at least one computer into the test group.

To create a test group

1. In the WSUS Administration Console, expand Computers and select All Computers.
2. Right-click All Computers and click Add Computer Group.
3. In the Add Computer Group dialog box, specify the Name of the new test group and click Add.

In the next procedure, you will assign a client computer to the test group. A test computer is any computer that has software and hardware that is consistent with the majority of client computers on the network, yet not assigned to a critical role. After your tests are successful, you can approve the updates for computers in the groups of your choice.

To assign a computer to the test group

1. In the WSUS Administration Console, click Computers.
2. Click the group of the computer that you want to assign to the test group.
3. In the list of computers, select the computer or computers that you want to assign to the test group.
4. Right-click Change Membership.
5. In the Set Computer Group Membership dialog box, select the test group that you created previously, and then click OK.

Repeat these two procedures, that is, create a group and then assign computer(s) to the group, to create as many additional computer groups as needed to manage updates at your site.

Step 7: Approve and deploy WSUS updates

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Standard

In this step, you approve an update for any computers in the test group for WSUS 3.0 SP2. Computers in the group automatically contact the WSUS server over the next 24 hours to obtain the update. You can use the WSUS reporting feature to determine whether those updates were deployed to the test computers. When the tests are successfully completed, you can then approve the updates for the applicable computer groups in your organization.

Step 7 Procedures

• Approve and deploy an update.
• Check the status of an update.

To approve and deploy an update

1. On the WSUS Administration Console, click Updates. An update status summary is displayed for All Updates, Critical Updates, Security Updates, and WSUS Updates.
2. In the All Updates section, click Updates needed by computers.
3. On the list of updates, select the updates that you want to approve for installation on your test computer group. Information about a selected update is available in the bottom pane of the Updates panel. To select multiple contiguous updates, hold down the SHIFT key while clicking updates; to select multiple noncontiguous updates, press down the CTRL key while clicking updates.
4. Right-click the selection and click Approve.
5. In the Approve Updates dialog box, select your test group, and then click the down arrow.
6. Click Approved for Install and then click OK.
7. The Approval Progress window appears which shows progress of the tasks that affect update approval. When approval is completed, click Close.

After 24 hours, you can use the WSUS Reports feature to determine whether the updates were deployed to the test group computers.

To check the status of an update

1. In the navigation pane of the WSUS Administration Console, click Reports.
2. On the Reports page, click the Update Status Summary report. The Updates Report window appears.
3. If you want to filter the list of updates, select the criteria that you want to use, for example, Include updates in these classifications, and then click Run Report on the window's toolbar.
4. You will see the Updates Report pane. You can check the status of individual updates by selecting the update in the left section of the pane. The last section of the report pane shows the status summary of the update.
5. You can save or print this report by clicking the applicable icon on the toolbar.
6. After you test the updates, you can approve the updates for installation on the applicable computer groups in your organization.

How to Break WinRAR Package Password in Ubuntu (Easy Way)

I’m gonna share to you some cool and easy way to break your Winrar Password Package in Ubuntu. You can use this method in case you forget your Winrar Password or kind like that. Ok, let’s get started.

First, you must know that software that will perform the RAR Package Crack, the software name is “RarCrack”. And this is the method to download and install RARCRACK. You can download the latest version (0.2) from this website  .

Or simply follow this simple tutorial to perform the installation.

First, download the rarcrack 0.2 by pasting this following code:

Download rarcrack 0.2

tar xvjf rarcrack-0.2.tar.bz2

Get into the RarCrack Folder

cd rarcrack-0.2

install some needed dependencies by typing this following code:

sudo apt-get install libxml2-dev

Install the RarCrack

make ; sudo make install

Alright! That’s the end of RarCrack Installation. Ok, that’s not entirely true, there’s one of the most important part that you forget, the cracking part  . To crack or break the RAR Package Password, type in terminal:

rarcrack /home/UserName/example.rar

Just simply put your .rar directory and perhaps if it’s not working try to rename your rar file, it probably will help.

This software is also works for other Package (zip and 7z), just simply replace .rar into .zip or .7z in case you must break zip or 7z passwd.

Thanks to melayubuntu that providing this simple and nice tutorial… Cheers!

Troubleshooting a Microsoft Windows MySQL Server Installation

Troubleshooting a Microsoft Windows MySQL Server Installation
When installing and running MySQL for the first time, you may encounter certain errors that prevent the MySQL server from starting. The purpose of this section is to help you diagnose and correct some of these errors.


Your first resource when troubleshooting server issues is the error log. The MySQL server uses the error log to record information relevant to the error that prevents the server from starting. The error log is located in the data directory specified in your my.ini file. The default data directory location is C:\Program Files\MySQL\MySQL Server 5.1\data, or C:\ProgramData\Mysql on Windows 7 and Windows Server 2008. The C:\ProgramData diectory is hidden by default. You need to change your folder options to see the directory and contents. For more information on the error log and understanding the content, see Section 5.2.2, “The Error Log”.

Another source of information regarding possible errors is the console messages displayed when the MySQL service is starting. Use the NET START MySQL command from the command line after installing mysqld as a service to see any error messages regarding the starting of the MySQL server as a service. See Section 2.3.5.7, “Starting MySQL Server as a Microsoft Windows Service”.

The following examples show other common error messages you may encounter when installing MySQL and starting the server for the first time:

• If the MySQL server cannot find the mysql privileges database or other critical files, you may see these messages:

• System error 1067 has occurred.

Fatal error: Can't open privilege tables: Table 'mysql.host' doesn't exist

These messages often occur when the MySQL base or data directories are installed in different locations than the default locations (C:\Program Files\MySQL\MySQL Server 5.1 and C:\Program Files\MySQL\MySQL Server 5.1\data, respectively).

This situation may occur when MySQL is upgraded and installed to a new location, but the configuration file is not updated to reflect the new location. In addition, there may be old and new configuration files that conflict. Be sure to delete or rename any old configuration files when upgrading MySQL.

If you have installed MySQL to a directory other than C:\Program Files\MySQL\MySQL Server 5.1, you need to ensure that the MySQL server is aware of this through the use of a configuration (my.ini) file. The my.ini file needs to be located in your Windows directory, typically C:\WINDOWS. You can determine its exact location from the value of the WINDIR environment variable by issuing the following command from the command prompt:

C:\> echo %WINDIR%

An option file can be created and modified with any text editor, such as Notepad. For example, if MySQL is installed in E:\mysql and the data directory is D:\MySQLdata, you can create the option file and set up a [mysqld] section to specify values for the basedir and datadir options:

[mysqld]

# set basedir to your installation path

basedir=E:/mysql

# set datadir to the location of your data directory

datadir=D:/MySQLdata

Note that Windows path names are specified in option files using (forward) slashes rather than backslashes. If you do use backslashes, double them:

[mysqld]

# set basedir to your installation path

basedir=C:\\Program Files\\MySQL\\MySQL Server 5.1

# set datadir to the location of your data directory

datadir=D:\\MySQLdata

The rules for use of backslash in option file values are given in Section 4.2.3.3, “Using Option Files”.

If you change the datadir value in your MySQL configuration file, you must move the contents of the existing MySQL data directory before restarting the MySQL server.

• If you reinstall or upgrade MySQL without first stopping and removing the existing MySQL service and install MySQL using the MySQL Config Wizard, you may see this error:

Error: Cannot create Windows service for MySql. Error: 0

This occurs when the Config Wizard tries to install the service and finds an existing service with the same name.

One solution to this problem is to choose a service name other than mysql when using the configuration wizard. This enables the new service to be installed correctly, but leaves the outdated service in place. Although this is harmless, it is best to remove old services that are no longer in use.

To permanently remove the old mysql service, execute the following command as a user with administrative privileges, on the command-line:

C:\> sc delete mysql

[SC] DeleteService SUCCESS

If the sc utility is not available for your version of Windows, download the delsrv utility from http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/delsrv-o.asp and use the delsrv mysql syntax.



C.5.4.1. How to Reset the Root Password

If you have never set a root password for MySQL, the server does not require a password at all for connecting as root. However, this is insecure. For instructions on assigning passwords, see Section 2.12.2, “Securing the Initial MySQL Accounts”.

If you know the root password, but want to change it, see Section 12.7.1.6, “SET PASSWORD Syntax”.

If you set a root password previously, but have forgotten it, you can set a new password. The following sections provide instructions for Windows and Unix systems, as well as generic instructions that apply to any system.

C.5.4.1.1. Resetting the Root Password: Windows Systems

On Windows, use the following procedure to reset the password for all MySQL root accounts:

1. Log on to your system as Administrator.

2. Stop the MySQL server if it is running. For a server that is running as a Windows service, go to the Services manager: From the Start menu, select Control Panel, then Administrative Tools, then Services. Find the MySQL service in the list and stop it.

If your server is not running as a service, you may need to use the Task Manager to force it to stop.

3. Create a text file containing the following statements. Replace the password with the password that you want to use.

4. UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root';

FLUSH PRIVILEGES;

Write the UPDATE and FLUSH statements each on a single line. The UPDATE statement resets the password for all root accounts, and the FLUSH statement tells the server to reload the grant tables into memory so that it notices the password change.

5. Save the file. For this example, the file will be named C:\mysql-init.txt.

6. Open a console window to get to the command prompt: From the Start menu, select Run, then enter cmd as the command to be run.

7. Start the MySQL server with the special --init-file option (notice that the backslash in the option value is doubled):

8. C:\> C:\mysql\bin\mysqld --init-file=C:\\mysql-init.txt

If you installed MySQL to a location other than C:\mysql, adjust the command accordingly.

The server executes the contents of the file named by the --init-file option at startup, changing each root account password.

You can also add the --console option to the command if you want server output to appear in the console window rather than in a log file.

If you installed MySQL using the MySQL Installation Wizard, you may need to specify a --defaults-file option:

C:\> "C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld.exe"

--defaults-file="C:\\Program Files\\MySQL\\MySQL Server 5.1\\my.ini"

--init-file=C:\\mysql-init.txt

The appropriate --defaults-file setting can be found using the Services Manager: From the Start menu, select Control Panel, then Administrative Tools, then Services. Find the MySQL service in the list, right-click it, and choose the Properties option. The Path to executable field contains the --defaults-file setting.

9. After the server has started successfully, delete C:\mysql-init.txt.

You should now be able to connect to the MySQL server as root using the new password. Stop the MySQL server, then restart it in normal mode again. If you run the server as a service, start it from the Windows Services window. If you start the server manually, use whatever command you normally use.

C.5.4.1.2. Resetting the Root Password: Unix Systems

On Unix, use the following procedure to reset the password for all MySQL root accounts. The instructions assume that you will start the server so that it runs using the Unix login account that you normally use for running the server. For example, if you run the server using the mysql login account, you should log in as mysql before using the instructions. Alternatively, you can log in as root, but in this case you must start mysqld with the --user=mysql option. If you start the server as root without using --user=mysql, the server may create root-owned files in the data directory, such as log files, and these may cause permission-related problems for future server startups. If that happens, you will need to either change the ownership of the files to mysql or remove them.

1. Log on to your system as the Unix user that the mysqld server runs as (for example, mysql).

2. Locate the .pid file that contains the server's process ID. The exact location and name of this file depend on your distribution, host name, and configuration. Common locations are /var/lib/mysql/, /var/run/mysqld/, and /usr/local/mysql/data/. Generally, the file name has an extension of .pid and begins with either mysqld or your system's host name.

You can stop the MySQL server by sending a normal kill (not kill -9) to the mysqld process, using the path name of the .pid file in the following command:

shell> kill `cat /mysql-data-directory/host_name.pid`

Use backticks (not forward quotation marks) with the cat command. These cause the output of cat to be substituted into the kill command.

3. Create a text file containing the following statements. Replace the password with the password that you want to use.

4. UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root';

FLUSH PRIVILEGES;

Write the UPDATE and FLUSH statements each on a single line. The UPDATE statement resets the password for all root accounts, and the FLUSH statement tells the server to reload the grant tables into memory so that it notices the password change.

5. Save the file. For this example, the file will be named /home/me/mysql-init. The file contains the password, so it should not be saved where it can be read by other users. If you are not logged in as mysql (the user the server runs as), make sure that the file has permissions that permit mysql to read it.

6. Start the MySQL server with the special --init-file option:

7. shell> mysqld_safe --init-file=/home/me/mysql-init &

The server executes the contents of the file named by the --init-file option at startup, changing each root account password.

8. After the server has started successfully, delete /home/me/mysql-init.

You should now be able to connect to the MySQL server as root using the new password. Stop the server and restart it normally.

C.5.4.1.3. Resetting the Root Password: Generic Instructions

The preceding sections provide password-resetting instructions for Windows and Unix systems. Alternatively, on any platform, you can set the new password using the mysql client (but this approach is less secure):

1. Stop mysqld and restart it with the --skip-grant-tables option. This enables anyone to connect without a password and with all privileges. Because this is insecure, you might want to use --skip-grant-tables in conjunction with --skip-networking to prevent remote clients from connecting.

2. Connect to the mysqld server with this command:

3. shell> mysql

4. Issue the following statements in the mysql client. Replace the password with the password that you want to use.

5. mysql> UPDATE mysql.user SET Password=PASSWORD('MyNewPass')

6. -> WHERE User='root';

7. mysql> FLUSH PRIVILEGES;

The FLUSH statement tells the server to reload the grant tables into memory so that it notices the password change.

You should now be able to connect to the MySQL server as root using the new password. Stop the server, then restart it normally (without the --skip-grant-tables and --skip-networking options).






C.5.4.2. What to Do If MySQL Keeps Crashing

Each MySQL version is tested on many platforms before it is released. This doesn't mean that there are no bugs in MySQL, but if there are bugs, they should be very few and can be hard to find. If you have a problem, it always helps if you try to find out exactly what crashes your system, because you have a much better chance of getting the problem fixed quickly.

First, you should try to find out whether the problem is that the mysqld server dies or whether your problem has to do with your client. You can check how long your mysqld server has been up by executing mysqladmin version. If mysqld has died and restarted, you may find the reason by looking in the server's error log. See Section 5.2.2, “The Error Log”.

On some systems, you can find in the error log a stack trace of where mysqld died that you can resolve with the resolve_stack_dump program. See MySQL Internals: Porting. Note that the variable values written in the error log may not always be 100% correct.

Many server crashes are caused by corrupted data files or index files. MySQL updates the files on disk with the write() system call after every SQL statement and before the client is notified about the result. (This is not true if you are running with --delay-key-write, in which case data files are written but not index files.) This means that data file contents are safe even if mysqld crashes, because the operating system ensures that the unflushed data is written to disk. You can force MySQL to flush everything to disk after every SQL statement by starting mysqld with the --flush option.

The preceding means that normally you should not get corrupted tables unless one of the following happens:

• The MySQL server or the server host was killed in the middle of an update.

• You have found a bug in mysqld that caused it to die in the middle of an update.

• Some external program is manipulating data files or index files at the same time as mysqld without locking the table properly.

• You are running many mysqld servers using the same data directory on a system that doesn't support good file system locks (normally handled by the lockd lock manager), or you are running multiple servers with external locking disabled.

• You have a crashed data file or index file that contains very corrupt data that confused mysqld.

• You have found a bug in the data storage code. This isn't likely, but it is at least possible. In this case, you can try to change the storage engine to another engine by using ALTER TABLE on a repaired copy of the table.

Because it is very difficult to know why something is crashing, first try to check whether things that work for others crash for you. Please try the following things:

• Stop the mysqld server with mysqladmin shutdown, run myisamchk --silent --force */*.MYI from the data directory to check all MyISAM tables, and restart mysqld. This ensures that you are running from a clean state. See Chapter 5, MySQL Server Administration.

• Start mysqld with the general query log enabled (see Section 5.2.3, “The General Query Log”). Then try to determine from the information written to the log whether some specific query kills the server. About 95% of all bugs are related to a particular query. Normally, this is one of the last queries in the log file just before the server restarts. See Section 5.2.3, “The General Query Log”. If you can repeatedly kill MySQL with a specific query, even when you have checked all tables just before issuing it, then you have been able to locate the bug and should submit a bug report for it. See Section 1.7, “How to Report Bugs or Problems”.

• Try to make a test case that we can use to repeat the problem. See MySQL Internals: Porting.

• Try running the tests in the mysql-test directory and the MySQL benchmarks. See Section 21.1.2, “The MySQL Test Suite”. They should test MySQL rather well. You can also add code to the benchmarks that simulates your application. The benchmarks can be found in the sql-bench directory in a source distribution or, for a binary distribution, in the sql-bench directory under your MySQL installation directory.

• Try the fork_big.pl script. (It is located in the tests directory of source distributions.)

• If you configure MySQL for debugging, it is much easier to gather information about possible errors if something goes wrong. Configuring MySQL for debugging causes a safe memory allocator to be included that can find some errors. It also provides a lot of output about what is happening. Reconfigure MySQL with the --with-debug or --with-debug=full option to configure and then recompile. See MySQL Internals: Porting.

• Make sure that you have applied the latest patches for your operating system.

• Use the --skip-external-locking option to mysqld. On some systems, the lockd lock manager does not work properly; the --skip-external-locking option tells mysqld not to use external locking. (This means that you cannot run two mysqld servers on the same data directory and that you must be careful if you use myisamchk. Nevertheless, it may be instructive to try the option as a test.)

• Have you tried mysqladmin -u root processlist when mysqld appears to be running but not responding? Sometimes mysqld is not comatose even though you might think so. The problem may be that all connections are in use, or there may be some internal lock problem. mysqladmin -u root processlist usually is able to make a connection even in these cases, and can provide useful information about the current number of connections and their status.

• Run the command mysqladmin -i 5 status or mysqladmin -i 5 -r status in a separate window to produce statistics while you run your other queries.

• Try the following:

a. Start mysqld from gdb (or another debugger). See MySQL Internals: Porting.

b. Run your test scripts.

c. Print the backtrace and the local variables at the three lowest levels. In gdb, you can do this with the following commands when mysqld has crashed inside gdb:

d. backtrace

e. info local

f. up

g. info local

h. up

info local

With gdb, you can also examine which threads exist with info threads and switch to a specific thread with thread N, where N is the thread ID.

• Try to simulate your application with a Perl script to force MySQL to crash or misbehave.

• Send a normal bug report. See Section 1.7, “How to Report Bugs or Problems”. Be even more detailed than usual. Because MySQL works for many people, it may be that the crash results from something that exists only on your computer (for example, an error that is related to your particular system libraries).

• If you have a problem with tables containing dynamic-length rows and you are using only VARCHAR columns (not BLOB or TEXT columns), you can try to change all VARCHAR to CHAR with ALTER TABLE. This forces MySQL to use fixed-size rows. Fixed-size rows take a little extra space, but are much more tolerant to corruption.

The current dynamic row code has been in use for several years with very few problems, but dynamic-length rows are by nature more prone to errors, so it may be a good idea to try this strategy to see whether it helps.

• Do not rule out your server hardware when diagnosing problems. Defective hardware can be the cause of data corruption. Particular attention should be paid to your memory and disk subsystems when troubleshooting hardware.

C.5.4.6. Time Zone Problems

If you have a problem with SELECT NOW() returning values in UTC and not your local time, you have to tell the server your current time zone. The same applies if UNIX_TIMESTAMP() returns the wrong value. This should be done for the environment in which the server runs; for example, in mysqld_safe or mysql.server. See Section 2.14, “Environment Variables”.

You can set the time zone for the server with the --timezone=timezone_name option to mysqld_safe. You can also set it by setting the TZ environment variable before you start mysqld.

The permissible values for --timezone or TZ are system dependent. Consult your operating system documentation to see what values are acceptable.

C.5.4.4. Where MySQL Stores Temporary Files

On Unix, MySQL uses the value of the TMPDIR environment variable as the path name of the directory in which to store temporary files. If TMPDIR is not set, MySQL uses the system default, which is usually /tmp, /var/tmp, or /usr/tmp.

On Windows, Netware and OS2, MySQL checks in order the values of the TMPDIR, TEMP, and TMP environment variables. For the first one found to be set, MySQL uses it and does not check those remaining. If none of TMPDIR, TEMP, or TMP are set, MySQL uses the Windows system default, which is usually C:\windows\temp\.

If the file system containing your temporary file directory is too small, you can use the --tmpdir option to mysqld to specify a directory in a file system where you have enough space.

In MySQL 5.1, the --tmpdir option can be set to a list of several paths that are used in round-robin fashion. Paths should be separated by colon characters (“:”) on Unix and semicolon characters (“;”) on Windows, NetWare, and OS/2.

Note

To spread the load effectively, these paths should be located on different physical disks, not different partitions of the same disk.

If the MySQL server is acting as a replication slave, you should not set --tmpdir to point to a directory on a memory-based file system or to a directory that is cleared when the server host restarts. A replication slave needs some of its temporary files to survive a machine restart so that it can replicate temporary tables or LOAD DATA INFILE operations. If files in the temporary file directory are lost when the server restarts, replication fails.

MySQL creates all temporary files as hidden files. This ensures that the temporary files are removed if mysqld is terminated. The disadvantage of using hidden files is that you do not see a big temporary file that fills up the file system in which the temporary file directory is located.

When sorting (ORDER BY or GROUP BY), MySQL normally uses one or two temporary files. The maximum disk space required is determined by the following expression:

(length of what is sorted + sizeof(row pointer))

* number of matched rows

* 2

The row pointer size is usually four bytes, but may grow in the future for really big tables.

For some SELECT queries, MySQL also creates temporary SQL tables. These are not hidden and have names of the form SQL_*.

ALTER TABLE creates a temporary table in the same directory as the original table.

C.5.4.5. How to Protect or Change the MySQL Unix Socket File

The default location for the Unix socket file that the server uses for communication with local clients is /tmp/mysql.sock. (For some distribution formats, the directory might be different, such as /var/lib/mysql for RPMs.)

On some versions of Unix, anyone can delete files in the /tmp directory or other similar directories used for temporary files. If the socket file is located in such a directory on your system, this might cause problems.

On most versions of Unix, you can protect your /tmp directory so that files can be deleted only by their owners or the superuser (root). To do this, set the sticky bit on the /tmp directory by logging in as root and using the following command:

shell> chmod +t /tmp

You can check whether the sticky bit is set by executing ls -ld /tmp. If the last permission character is t, the bit is set.

Another approach is to change the place where the server creates the Unix socket file. If you do this, you should also let client programs know the new location of the file. You can specify the file location in several ways:

• Specify the path in a global or local option file. For example, put the following lines in /etc/my.cnf:

• [mysqld]

• socket=/path/to/socket

• [client]

socket=/path/to/socket

• Specify a --socket option on the command line to mysqld_safe and when you run client programs.

• Set the MYSQL_UNIX_PORT environment variable to the path of the Unix socket file.

• Recompile MySQL from source to use a different default Unix socket file location. Define the path to the file with the --with-unix-socket-path option when you run configure. See Section 2.11.4, “MySQL Source-Configuration Options”.

You can test whether the new socket location works by attempting to connect to the server with this command:

shell> mysqladmin --socket=/path/to/socket version