Every now and then, I get a "timeout expired" error message when trying to approve or reapprove selected updates. I usually try again and the approvals go through without a problem. For the past few days, however, I almost always get the error, sometimes on the first update I try to approve, sometimes some 20 updates in. The text of the message is:
"Windows Server Update Services error -- Web Page Dialog
Windows Server Update Services encountered an error.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
[Show Details] [Close]"
When I press "Show Details", the following information is given:
"System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. at Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException e) at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() at Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection connection) at Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String spName, DBParameterCollection args, IExecuteSPHandler handler) at Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g spName, DBParameterCollection args, Type resultType) at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid updateId, Int32 revisionNumber, Int32 deploymentAction, Guid targetGroupId, String adminName, DateTime deadline, Boolean isAssigned, DateTime goLiveTime, Int32 downloadPriority, Guid deploymentGuid, Boolean translateSqlException) at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId updateId, Int32 deploymentAction, Guid targetGroupId, DateTime deadline, String adminName) at Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on action, IComputerTargetGroup targetGroup, DateTime deadline) at Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on action, IComputerTargetGroup targetGroup) at Administration.Updates.UpdateProxy.Deploy(String xpostXml) at Administration.Updates.UpdateXPost.Page_Load(Object sender, EventArgs e)
at Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException e) at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() at Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection connection) at Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String spName, DBParameterCollection args, IExecuteSPHandler handler) at Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g spName, DBParameterCollection args, Type resultType) at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid updateId, Int32 revisionNumber, Int32 deploymentAction, Guid targetGroupId, String adminName, DateTime deadline, Boolean isAssigned, DateTime goLiveTime, Int32 downloadPriority, Guid deploymentGuid, Boolean translateSqlException) at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId updateId, Int32 deploymentAction, Guid targetGroupId, DateTime deadline, String adminName) at Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on action, IComputerTargetGroup targetGroup, DateTime deadline) at Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on action, IComputerTargetGroup targetGroup) at Administration.Updates.UpdateProxy.Deploy(String xpostXml) at Administration.Updates.UpdateXPost.Page_Load(Object sender, EventArgs e)"
Unfortunately, I know very little SQL, so I am at a loss as to how to troubleshoot this. I have completely disabled Symantec AntiVirus just in case, but this has not helped. According to Task Manager, the server's CPU utilization barely reached 25% during the approval process, when the error happens. SQL seems to be eating about 800MB of RAM, but I have 4GB, so this should not be a problem. There seem to be no latency problems on the server otherwise, so I really have no idea why this is happening. Would the resolution of this problem also address why approvals in general take extremely long, despite very fast hardware?
We have identified a few performance issues with update approval, especially when multiple updates are chosen for approval or the server has many target groups.
How many updates are you attempting to approve at a time? How many target groups are present on this server? What is your approval strategy? Could you cut-paste the approvals for a typical update in your WSUS server?
Thanks.
-- Rajiv Poonamalli [MSFT] Windows Server Update Services
This posting is provided "AS IS" with no warranties, and confers no rights
"Bohdan" <Boh...@discussions.microsoft.com> wrote in message
> Every now and then, I get a "timeout expired" error message when trying to > approve or reapprove selected updates. I usually try again and the > approvals > go through without a problem. For the past few days, however, I almost > always get the error, sometimes on the first update I try to approve, > sometimes some 20 updates in. The text of the message is:
> "Windows Server Update Services error -- Web Page Dialog
> Windows Server Update Services encountered an error.
> Timeout expired. The timeout period elapsed prior to completion of the > operation or the server is not responding.
> [Show Details] [Close]"
> When I press "Show Details", the following information is given:
> "System.Data.SqlClient.SqlException: Timeout expired. The timeout period > elapsed prior to completion of the operation or the server is not > responding. > at > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException > e) > at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() > at > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection > connection) > at Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String > spName, DBParameterCollection args, IExecuteSPHandler handler) > at > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g > spName, DBParameterCollection args, Type resultType) > at > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid > targetGroupId, > String adminName, DateTime deadline, Boolean isAssigned, DateTime > goLiveTime, > Int32 downloadPriority, Guid deploymentGuid, Boolean > translateSqlException) > at > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime deadline, > String adminName) > at > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > action, IComputerTargetGroup targetGroup, DateTime deadline) > at > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > action, IComputerTargetGroup targetGroup) > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) > at Administration.Updates.UpdateXPost.Page_Load(Object sender, EventArgs > e)
> at > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException > e) > at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() > at > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection > connection) > at Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String > spName, DBParameterCollection args, IExecuteSPHandler handler) > at > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g > spName, DBParameterCollection args, Type resultType) > at > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid > targetGroupId, > String adminName, DateTime deadline, Boolean isAssigned, DateTime > goLiveTime, > Int32 downloadPriority, Guid deploymentGuid, Boolean > translateSqlException) > at > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime deadline, > String adminName) > at > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > action, IComputerTargetGroup targetGroup, DateTime deadline) > at > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > action, IComputerTargetGroup targetGroup) > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) > at Administration.Updates.UpdateXPost.Page_Load(Object sender, EventArgs > e)"
> Unfortunately, I know very little SQL, so I am at a loss as to how to > troubleshoot this. I have completely disabled Symantec AntiVirus just in > case, but this has not helped. According to Task Manager, the server's > CPU > utilization barely reached 25% during the approval process, when the error > happens. SQL seems to be eating about 800MB of RAM, but I have 4GB, so > this > should not be a problem. There seem to be no latency problems on the > server > otherwise, so I really have no idea why this is happening. Would the > resolution of this problem also address why approvals in general take > extremely long, despite very fast hardware?
The WSUS environment here is still in an experimental stage, so I am changing the target groups and approvals fairly often before I settle down on any one particular strategy. However, the strategy I have been using fairly consistently for the past few days and will probably settle on is as follows:
1. All Computers. This group is allowed to detect all possible updates but not install. 2. Unassigned Computers - Same as All Computers. 3. Force - This is an experimental group which forces an installation of all possible updates by specifying a deadline of 12:00AM, 10/01/2005. 4. SP2 - This is the group to which computers are slowly being added through client-side targeting and a dedicated WSUS OU. Initially, this group denied all updates except for XP SP2, which it installed based on the GP schedule.
I now want the SP2 group to approve the installation of all possible critical updates in addition to SP2 and so am trying to approve some 550 or so updates according to this strategy. Sometimes I receive the timeout error after the first attempted approval, sometimes more get approved before the timeout. Today, WSUS managed to approve some 220 updates before timing out.
Additionally, it seems that every time I change approvals, the approval process takes longer and longer. The first time I approved updates, each approval took some 10 seconds. Today, each approval that manages to go through takes between 70 and 90 seconds EACH. Why this performance hit? Why are approvals so complicated and lengthy?
If you have any fixes or suggestions, please let me know. I would like to put this server into production soon, but it is quickly becoming a major headache, having to devote an entire business day just for approvals to happen (or not happen, as has been the case lately).
"Rajiv Poonamalli [MSFT]" wrote: > We have identified a few performance issues with update approval, especially > when multiple updates are chosen for approval or the server has many target > groups.
> How many updates are you attempting to approve at a time? > How many target groups are present on this server? > What is your approval strategy? Could you cut-paste the approvals for a > typical update in your WSUS server?
> Thanks.
> -- > Rajiv Poonamalli [MSFT] > Windows Server Update Services
> This posting is provided "AS IS" with no warranties, and confers no rights
> > Every now and then, I get a "timeout expired" error message when trying to > > approve or reapprove selected updates. I usually try again and the > > approvals > > go through without a problem. For the past few days, however, I almost > > always get the error, sometimes on the first update I try to approve, > > sometimes some 20 updates in. The text of the message is:
> > "Windows Server Update Services error -- Web Page Dialog
> > Windows Server Update Services encountered an error.
> > Timeout expired. The timeout period elapsed prior to completion of the > > operation or the server is not responding.
> > [Show Details] [Close]"
> > When I press "Show Details", the following information is given:
> > "System.Data.SqlClient.SqlException: Timeout expired. The timeout period > > elapsed prior to completion of the operation or the server is not > > responding. > > at > > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException > > e) > > at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() > > at > > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection > > connection) > > at Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String > > spName, DBParameterCollection args, IExecuteSPHandler handler) > > at > > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g > > spName, DBParameterCollection args, Type resultType) > > at > > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid > > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid > > targetGroupId, > > String adminName, DateTime deadline, Boolean isAssigned, DateTime > > goLiveTime, > > Int32 downloadPriority, Guid deploymentGuid, Boolean > > translateSqlException) > > at > > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId > > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime deadline, > > String adminName) > > at > > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > > action, IComputerTargetGroup targetGroup, DateTime deadline) > > at > > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > > action, IComputerTargetGroup targetGroup) > > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) > > at Administration.Updates.UpdateXPost.Page_Load(Object sender, EventArgs > > e)
> > at > > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException > > e) > > at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() > > at > > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection > > connection) > > at Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String > > spName, DBParameterCollection args, IExecuteSPHandler handler) > > at > > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g > > spName, DBParameterCollection args, Type resultType) > > at > > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid > > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid > > targetGroupId, > > String adminName, DateTime deadline, Boolean isAssigned, DateTime > > goLiveTime, > > Int32 downloadPriority, Guid deploymentGuid, Boolean > > translateSqlException) > > at > > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId > > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime deadline, > > String adminName) > > at > > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > > action, IComputerTargetGroup targetGroup, DateTime deadline) > > at > > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > > action, IComputerTargetGroup targetGroup) > > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) > > at Administration.Updates.UpdateXPost.Page_Load(Object sender, EventArgs > > e)"
> > Unfortunately, I know very little SQL, so I am at a loss as to how to > > troubleshoot this. I have completely disabled Symantec AntiVirus just in > > case, but this has not helped. According to Task Manager, the server's > > CPU > > utilization barely reached 25% during the approval process, when the error > > happens. SQL seems to be eating about 800MB of RAM, but I have 4GB, so > > this > > should not be a problem. There seem to be no latency problems on the > > server > > otherwise, so I really have no idea why this is happening. Would the > > resolution of this problem also address why approvals in general take > > extremely long, despite very fast hardware?
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Bohdan" <Boh...@discussions.microsoft.com> wrote in message
> The WSUS environment here is still in an experimental stage, so I am > changing the target groups and approvals fairly often before I settle down > on > any one particular strategy. However, the strategy I have been using > fairly > consistently for the past few days and will probably settle on is as > follows:
> 1. All Computers. This group is allowed to detect all possible updates > but > not install. > 2. Unassigned Computers - Same as All Computers. > 3. Force - This is an experimental group which forces an installation of > all > possible updates by specifying a deadline of 12:00AM, 10/01/2005. > 4. SP2 - This is the group to which computers are slowly being added > through > client-side targeting and a dedicated WSUS OU. Initially, this group > denied > all updates except for XP SP2, which it installed based on the GP > schedule.
> I now want the SP2 group to approve the installation of all possible > critical updates in addition to SP2 and so am trying to approve some 550 > or > so updates according to this strategy. Sometimes I receive the timeout > error > after the first attempted approval, sometimes more get approved before the > timeout. Today, WSUS managed to approve some 220 updates before timing > out.
> Additionally, it seems that every time I change approvals, the approval > process takes longer and longer. The first time I approved updates, each > approval took some 10 seconds. Today, each approval that manages to go > through takes between 70 and 90 seconds EACH. Why this performance hit? > Why > are approvals so complicated and lengthy?
> If you have any fixes or suggestions, please let me know. I would like to > put this server into production soon, but it is quickly becoming a major > headache, having to devote an entire business day just for approvals to > happen (or not happen, as has been the case lately).
> Thanks,
> Bohdan
> "Rajiv Poonamalli [MSFT]" wrote:
>> We have identified a few performance issues with update approval, >> especially >> when multiple updates are chosen for approval or the server has many >> target >> groups.
>> How many updates are you attempting to approve at a time? >> How many target groups are present on this server? >> What is your approval strategy? Could you cut-paste the approvals for a >> typical update in your WSUS server?
>> Thanks.
>> -- >> Rajiv Poonamalli [MSFT] >> Windows Server Update Services
>> This posting is provided "AS IS" with no warranties, and confers no >> rights
>> > Every now and then, I get a "timeout expired" error message when trying >> > to >> > approve or reapprove selected updates. I usually try again and the >> > approvals >> > go through without a problem. For the past few days, however, I almost >> > always get the error, sometimes on the first update I try to approve, >> > sometimes some 20 updates in. The text of the message is:
>> > "Windows Server Update Services error -- Web Page Dialog
>> > Windows Server Update Services encountered an error.
>> > Timeout expired. The timeout period elapsed prior to completion of the >> > operation or the server is not responding.
>> > [Show Details] [Close]"
>> > When I press "Show Details", the following information is given:
>> > "System.Data.SqlClient.SqlException: Timeout expired. The timeout >> > period >> > elapsed prior to completion of the operation or the server is not >> > responding. >> > at >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException >> > e) >> > at >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() >> > at >> > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection >> > connection) >> > at >> > Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String >> > spName, DBParameterCollection args, IExecuteSPHandler handler) >> > at >> > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g >> > spName, DBParameterCollection args, Type resultType) >> > at >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid >> > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid >> > targetGroupId, >> > String adminName, DateTime deadline, Boolean isAssigned, DateTime >> > goLiveTime, >> > Int32 downloadPriority, Guid deploymentGuid, Boolean >> > translateSqlException) >> > at >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId >> > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime >> > deadline, >> > String adminName) >> > at >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >> > action, IComputerTargetGroup targetGroup, DateTime deadline) >> > at >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >> > action, IComputerTargetGroup targetGroup) >> > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) >> > at Administration.Updates.UpdateXPost.Page_Load(Object sender, >> > EventArgs >> > e)
>> > Unfortunately, I know very little SQL, so I am at a loss as to how to >> > troubleshoot this. I have completely disabled Symantec AntiVirus just >> > in >> > case, but this has not helped. According to Task Manager, the server's >> > CPU >> > utilization barely reached 25% during the approval process, when the >> > error >> > happens. SQL seems to be eating about 800MB of RAM, but I have 4GB, so >> > this >> > should not be a problem. There seem to be no latency problems on the >> > server >> > otherwise, so I really have no idea why this is happening. Would the >> > resolution of this problem also address why approvals in general take >> > extremely long, despite very fast hardware?
"David Hennessey (MSFT)" wrote: > Are you running Full SQL or WMSDE?
> -- > This posting is provided "As Is" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm
> > The WSUS environment here is still in an experimental stage, so I am > > changing the target groups and approvals fairly often before I settle down > > on > > any one particular strategy. However, the strategy I have been using > > fairly > > consistently for the past few days and will probably settle on is as > > follows:
> > 1. All Computers. This group is allowed to detect all possible updates > > but > > not install. > > 2. Unassigned Computers - Same as All Computers. > > 3. Force - This is an experimental group which forces an installation of > > all > > possible updates by specifying a deadline of 12:00AM, 10/01/2005. > > 4. SP2 - This is the group to which computers are slowly being added > > through > > client-side targeting and a dedicated WSUS OU. Initially, this group > > denied > > all updates except for XP SP2, which it installed based on the GP > > schedule.
> > I now want the SP2 group to approve the installation of all possible > > critical updates in addition to SP2 and so am trying to approve some 550 > > or > > so updates according to this strategy. Sometimes I receive the timeout > > error > > after the first attempted approval, sometimes more get approved before the > > timeout. Today, WSUS managed to approve some 220 updates before timing > > out.
> > Additionally, it seems that every time I change approvals, the approval > > process takes longer and longer. The first time I approved updates, each > > approval took some 10 seconds. Today, each approval that manages to go > > through takes between 70 and 90 seconds EACH. Why this performance hit? > > Why > > are approvals so complicated and lengthy?
> > If you have any fixes or suggestions, please let me know. I would like to > > put this server into production soon, but it is quickly becoming a major > > headache, having to devote an entire business day just for approvals to > > happen (or not happen, as has been the case lately).
> > Thanks,
> > Bohdan
> > "Rajiv Poonamalli [MSFT]" wrote:
> >> We have identified a few performance issues with update approval, > >> especially > >> when multiple updates are chosen for approval or the server has many > >> target > >> groups.
> >> How many updates are you attempting to approve at a time? > >> How many target groups are present on this server? > >> What is your approval strategy? Could you cut-paste the approvals for a > >> typical update in your WSUS server?
> >> Thanks.
> >> -- > >> Rajiv Poonamalli [MSFT] > >> Windows Server Update Services
> >> This posting is provided "AS IS" with no warranties, and confers no > >> rights
> >> > Every now and then, I get a "timeout expired" error message when trying > >> > to > >> > approve or reapprove selected updates. I usually try again and the > >> > approvals > >> > go through without a problem. For the past few days, however, I almost > >> > always get the error, sometimes on the first update I try to approve, > >> > sometimes some 20 updates in. The text of the message is:
> >> > "Windows Server Update Services error -- Web Page Dialog
> >> > Windows Server Update Services encountered an error.
> >> > Timeout expired. The timeout period elapsed prior to completion of the > >> > operation or the server is not responding.
> >> > [Show Details] [Close]"
> >> > When I press "Show Details", the following information is given:
> >> > "System.Data.SqlClient.SqlException: Timeout expired. The timeout > >> > period > >> > elapsed prior to completion of the operation or the server is not > >> > responding. > >> > at > >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException > >> > e) > >> > at > >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() > >> > at > >> > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection > >> > connection) > >> > at > >> > Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String > >> > spName, DBParameterCollection args, IExecuteSPHandler handler) > >> > at > >> > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g > >> > spName, DBParameterCollection args, Type resultType) > >> > at > >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid > >> > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid > >> > targetGroupId, > >> > String adminName, DateTime deadline, Boolean isAssigned, DateTime > >> > goLiveTime, > >> > Int32 downloadPriority, Guid deploymentGuid, Boolean > >> > translateSqlException) > >> > at > >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId > >> > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime > >> > deadline, > >> > String adminName) > >> > at > >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > >> > action, IComputerTargetGroup targetGroup, DateTime deadline) > >> > at > >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on > >> > action, IComputerTargetGroup targetGroup) > >> > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) > >> > at Administration.Updates.UpdateXPost.Page_Load(Object sender, > >> > EventArgs > >> > e)
> >> > Unfortunately, I know very little SQL, so I am at a loss as to how to > >> > troubleshoot this. I have completely disabled Symantec AntiVirus just > >> > in > >> > case, but this has not helped. According to Task Manager, the server's > >> > CPU > >> > utilization barely reached 25% during the approval process, when the > >> > error > >> > happens. SQL seems to be eating about 800MB of RAM, but I have 4GB, so > >> > this > >> > should not be a problem. There seem to be no latency problems on the > >> > server > >> > otherwise, so I really have no idea why this is happening. Would the > >> > resolution of this problem also address why approvals in general take > >> > extremely long, despite very fast hardware?
Bohdan, We are currently in the process of addressing some of the performance issues in this area. The steps below would fix part of the performance problems you are facing. Please try these on your server and let us know if it solves the timeout issues.
1) Save the attached file to disk on the WSUS server 2) As administrator, run the following command. osql -E -S <MSDEServerName> -n -b -i addDeploymentIndex.sql
The osql utility can be found in under the Program Files\Update Services\Tools folder.
-- Rajiv Poonamalli [MSFT] Windows Server Update Services
This posting is provided "AS IS" with no warranties, and confers no rights
"Bohdan" <Boh...@discussions.microsoft.com> wrote in message
> MSDE, with whatever patches and updates are currently available. The WSUS > server is Windows 2000 Standard, with SP4.
> "David Hennessey (MSFT)" wrote:
>> Are you running Full SQL or WMSDE?
>> -- >> This posting is provided "As Is" with no warranties, and confers no >> rights. >> Use of included script samples are subject to the terms specified at >> http://www.microsoft.com/info/cpyright.htm
>> > The WSUS environment here is still in an experimental stage, so I am >> > changing the target groups and approvals fairly often before I settle >> > down >> > on >> > any one particular strategy. However, the strategy I have been using >> > fairly >> > consistently for the past few days and will probably settle on is as >> > follows:
>> > 1. All Computers. This group is allowed to detect all possible updates >> > but >> > not install. >> > 2. Unassigned Computers - Same as All Computers. >> > 3. Force - This is an experimental group which forces an installation >> > of >> > all >> > possible updates by specifying a deadline of 12:00AM, 10/01/2005. >> > 4. SP2 - This is the group to which computers are slowly being added >> > through >> > client-side targeting and a dedicated WSUS OU. Initially, this group >> > denied >> > all updates except for XP SP2, which it installed based on the GP >> > schedule.
>> > I now want the SP2 group to approve the installation of all possible >> > critical updates in addition to SP2 and so am trying to approve some >> > 550 >> > or >> > so updates according to this strategy. Sometimes I receive the timeout >> > error >> > after the first attempted approval, sometimes more get approved before >> > the >> > timeout. Today, WSUS managed to approve some 220 updates before timing >> > out.
>> > Additionally, it seems that every time I change approvals, the approval >> > process takes longer and longer. The first time I approved updates, >> > each >> > approval took some 10 seconds. Today, each approval that manages to go >> > through takes between 70 and 90 seconds EACH. Why this performance >> > hit? >> > Why >> > are approvals so complicated and lengthy?
>> > If you have any fixes or suggestions, please let me know. I would like >> > to >> > put this server into production soon, but it is quickly becoming a >> > major >> > headache, having to devote an entire business day just for approvals to >> > happen (or not happen, as has been the case lately).
>> > Thanks,
>> > Bohdan
>> > "Rajiv Poonamalli [MSFT]" wrote:
>> >> We have identified a few performance issues with update approval, >> >> especially >> >> when multiple updates are chosen for approval or the server has many >> >> target >> >> groups.
>> >> How many updates are you attempting to approve at a time? >> >> How many target groups are present on this server? >> >> What is your approval strategy? Could you cut-paste the approvals for >> >> a >> >> typical update in your WSUS server?
>> >> Thanks.
>> >> -- >> >> Rajiv Poonamalli [MSFT] >> >> Windows Server Update Services
>> >> This posting is provided "AS IS" with no warranties, and confers no >> >> rights
>> >> > Every now and then, I get a "timeout expired" error message when >> >> > trying >> >> > to >> >> > approve or reapprove selected updates. I usually try again and the >> >> > approvals >> >> > go through without a problem. For the past few days, however, I >> >> > almost >> >> > always get the error, sometimes on the first update I try to >> >> > approve, >> >> > sometimes some 20 updates in. The text of the message is:
>> >> > "Windows Server Update Services error -- Web Page Dialog
>> >> > Windows Server Update Services encountered an error.
>> >> > Timeout expired. The timeout period elapsed prior to completion of >> >> > the >> >> > operation or the server is not responding.
>> >> > [Show Details] [Close]"
>> >> > When I press "Show Details", the following information is given:
>> >> > "System.Data.SqlClient.SqlException: Timeout expired. The timeout >> >> > period >> >> > elapsed prior to completion of the operation or the server is not >> >> > responding. >> >> > at >> >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException >> >> > e) >> >> > at >> >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() >> >> > at >> >> > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection >> >> > connection) >> >> > at >> >> > Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String >> >> > spName, DBParameterCollection args, IExecuteSPHandler handler) >> >> > at >> >> > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g >> >> > spName, DBParameterCollection args, Type resultType) >> >> > at >> >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid >> >> > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid >> >> > targetGroupId, >> >> > String adminName, DateTime deadline, Boolean isAssigned, DateTime >> >> > goLiveTime, >> >> > Int32 downloadPriority, Guid deploymentGuid, Boolean >> >> > translateSqlException) >> >> > at >> >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId >> >> > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime >> >> > deadline, >> >> > String adminName) >> >> > at >> >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >> >> > action, IComputerTargetGroup targetGroup, DateTime deadline) >> >> > at >> >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >> >> > action, IComputerTargetGroup targetGroup) >> >> > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) >> >> > at Administration.Updates.UpdateXPost.Page_Load(Object sender, >> >> > EventArgs >> >> > e)
>> >> > Unfortunately, I know very little SQL, so I am at a loss as to how >> >> > to >> >> > troubleshoot this. I have completely disabled Symantec AntiVirus >> >> > just >> >> > in >> >> > case, but this has not helped. According to Task Manager, the >> >> > server's >> >> > CPU >> >> > utilization barely reached 25% during the approval process, when the >> >> > error >> >> > happens. SQL seems to be eating about 800MB of RAM, but I have 4GB, >> >> > so >> >> > this >> >> > should not be a problem. There seem to be no latency problems on >> >> > the >> >> > server >> >> > otherwise, so I really have no idea why this is happening. Would >> >> > the >> >> > resolution of this problem also address why approvals in general >> >> > take >> >> > extremely long, despite very fast hardware?
>> >> > Help would be greatly appreciated.
>> >> > Bohdan
begin 666 addDeploymentIndex.sql M55-%(%-54T1"( T*1T\-"D)%1TE.(%1204X-"DE&($Y/5"!%6$E35%,@*%-% M3$5#5" J($923TT@<WES:6YD97AE<R!W:&5R92!N86UE/2=N8S=$97!L;WEM
...
Based on this comment: "so am trying to approve some 550 or so updates according to this strategy".
Since the actual number of updates that are applicable to an XP SP2 system is fairly short, might I suggest that you run a Computers report for one of your XP SP2 systems, itemize the updates that are actually showing as "Needed" for that XP SP2 system, and then approve /only/ that short list of updates for your XP SP2 systems.
Following a reasonable period of time for the detection and installation of those updates, run another Computers report and see if any additional updates are still listed as "Needed" by /any/ XP SP2 system, and approve those updates as well.
>Today, WSUS managed to approve some 220 updates before timing out.
This is an excessively large number of update to try to change in one shot, and quite frankly, is not even realistically representative of the actual updates that /need/ to be marked as Approved for Installation.
In short, you're probably creating much more work for yourself than is actually necessary.
"Bohdan" <Boh...@discussions.microsoft.com> wrote in message
> The WSUS environment here is still in an experimental stage, so I am > changing the target groups and approvals fairly often before I settle down > on > any one particular strategy. However, the strategy I have been using > fairly > consistently for the past few days and will probably settle on is as > follows:
> 1. All Computers. This group is allowed to detect all possible updates > but > not install. > 2. Unassigned Computers - Same as All Computers. > 3. Force - This is an experimental group which forces an installation of > all > possible updates by specifying a deadline of 12:00AM, 10/01/2005. > 4. SP2 - This is the group to which computers are slowly being added > through > client-side targeting and a dedicated WSUS OU. Initially, this group > denied > all updates except for XP SP2, which it installed based on the GP > schedule.
> I now want the SP2 group to approve the installation of all possible > critical updates in addition to SP2 and so am trying to approve some 550 > or > so updates according to this strategy. Sometimes I receive the timeout > error > after the first attempted approval, sometimes more get approved before the > timeout. Today, WSUS managed to approve some 220 updates before timing > out.
> Additionally, it seems that every time I change approvals, the approval > process takes longer and longer. The first time I approved updates, each > approval took some 10 seconds. Today, each approval that manages to go > through takes between 70 and 90 seconds EACH. Why this performance hit? > Why > are approvals so complicated and lengthy?
> If you have any fixes or suggestions, please let me know. I would like to > put this server into production soon, but it is quickly becoming a major > headache, having to devote an entire business day just for approvals to > happen (or not happen, as has been the case lately).
> Thanks,
> Bohdan
> "Rajiv Poonamalli [MSFT]" wrote:
>> We have identified a few performance issues with update approval, >> especially >> when multiple updates are chosen for approval or the server has many >> target >> groups.
>> How many updates are you attempting to approve at a time? >> How many target groups are present on this server? >> What is your approval strategy? Could you cut-paste the approvals for a >> typical update in your WSUS server?
>> Thanks.
>> -- >> Rajiv Poonamalli [MSFT] >> Windows Server Update Services
>> This posting is provided "AS IS" with no warranties, and confers no >> rights
>> > Every now and then, I get a "timeout expired" error message when trying >> > to >> > approve or reapprove selected updates. I usually try again and the >> > approvals >> > go through without a problem. For the past few days, however, I almost >> > always get the error, sometimes on the first update I try to approve, >> > sometimes some 20 updates in. The text of the message is:
>> > "Windows Server Update Services error -- Web Page Dialog
>> > Windows Server Update Services encountered an error.
>> > Timeout expired. The timeout period elapsed prior to completion of the >> > operation or the server is not responding.
>> > [Show Details] [Close]"
>> > When I press "Show Details", the following information is given:
>> > "System.Data.SqlClient.SqlException: Timeout expired. The timeout >> > period >> > elapsed prior to completion of the operation or the server is not >> > responding. >> > at >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException >> > e) >> > at >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() >> > at >> > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection >> > connection) >> > at >> > Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String >> > spName, DBParameterCollection args, IExecuteSPHandler handler) >> > at >> > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g >> > spName, DBParameterCollection args, Type resultType) >> > at >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid >> > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid >> > targetGroupId, >> > String adminName, DateTime deadline, Boolean isAssigned, DateTime >> > goLiveTime, >> > Int32 downloadPriority, Guid deploymentGuid, Boolean >> > translateSqlException) >> > at >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId >> > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime >> > deadline, >> > String adminName) >> > at >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >> > action, IComputerTargetGroup targetGroup, DateTime deadline) >> > at >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >> > action, IComputerTargetGroup targetGroup) >> > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) >> > at Administration.Updates.UpdateXPost.Page_Load(Object sender, >> > EventArgs >> > e)
>> > Unfortunately, I know very little SQL, so I am at a loss as to how to >> > troubleshoot this. I have completely disabled Symantec AntiVirus just >> > in >> > case, but this has not helped. According to Task Manager, the server's >> > CPU >> > utilization barely reached 25% during the approval process, when the >> > error >> > happens. SQL seems to be eating about 800MB of RAM, but I have 4GB, so >> > this >> > should not be a problem. There seem to be no latency problems on the >> > server >> > otherwise, so I really have no idea why this is happening. Would the >> > resolution of this problem also address why approvals in general take >> > extremely long, despite very fast hardware?
I attempted to follow your advice by RDPing into the server and performing the steps you outlined. First, I found that the osql utility is actually in the osql subdirectory of Tools. I copied the sql file into the directory with the osql utility and ran the command exactly as you specified. I received an error, which I am pasting below. The name of my WSUS server is NY1221WSUS2K.
"C:\Program Files\Update Services\Tools\osql>osql -E -S NY1221WSUS2K -n -b -i add DeploymentIndex.sql Msg 911, Level 16, State 1, Server NY1221WSUS2K, Line 1 Could not locate entry in sysdatabases for database 'SUSDB'. No entry found with that name. Make sure that the name is entered correctly."
Am I doing something wrong, or is this not supported via RDP? Please advise.
> Bohdan, > We are currently in the process of addressing some of the performance > issues in this area. The steps below would fix part of the performance > problems you are facing. Please try these on your server and let us know > if it solves the timeout issues.
> 1) Save the attached file to disk on the WSUS server > 2) As administrator, run the following command. > osql -E -S <MSDEServerName> -n -b -i addDeploymentIndex.sql
> The osql utility can be found in under the Program Files\Update > Services\Tools folder.
> -- > Rajiv Poonamalli [MSFT] > Windows Server Update Services
> This posting is provided "AS IS" with no warranties, and confers no rights
> "Bohdan" <Boh...@discussions.microsoft.com> wrote in message > news:85813053-D2D6-4FBA-AB4E-70D83C6BFC8D@microsoft.com... >> MSDE, with whatever patches and updates are currently available. The >> WSUS >> server is Windows 2000 Standard, with SP4.
>> "David Hennessey (MSFT)" wrote:
>>> Are you running Full SQL or WMSDE?
>>> -- >>> This posting is provided "As Is" with no warranties, and confers no >>> rights. >>> Use of included script samples are subject to the terms specified at >>> http://www.microsoft.com/info/cpyright.htm
>>> > The WSUS environment here is still in an experimental stage, so I am >>> > changing the target groups and approvals fairly often before I settle >>> > down >>> > on >>> > any one particular strategy. However, the strategy I have been using >>> > fairly >>> > consistently for the past few days and will probably settle on is as >>> > follows:
>>> > 1. All Computers. This group is allowed to detect all possible >>> > updates >>> > but >>> > not install. >>> > 2. Unassigned Computers - Same as All Computers. >>> > 3. Force - This is an experimental group which forces an installation >>> > of >>> > all >>> > possible updates by specifying a deadline of 12:00AM, 10/01/2005. >>> > 4. SP2 - This is the group to which computers are slowly being added >>> > through >>> > client-side targeting and a dedicated WSUS OU. Initially, this group >>> > denied >>> > all updates except for XP SP2, which it installed based on the GP >>> > schedule.
>>> > I now want the SP2 group to approve the installation of all possible >>> > critical updates in addition to SP2 and so am trying to approve some >>> > 550 >>> > or >>> > so updates according to this strategy. Sometimes I receive the >>> > timeout >>> > error >>> > after the first attempted approval, sometimes more get approved before >>> > the >>> > timeout. Today, WSUS managed to approve some 220 updates before >>> > timing >>> > out.
>>> > Additionally, it seems that every time I change approvals, the >>> > approval >>> > process takes longer and longer. The first time I approved updates, >>> > each >>> > approval took some 10 seconds. Today, each approval that manages to >>> > go >>> > through takes between 70 and 90 seconds EACH. Why this performance >>> > hit? >>> > Why >>> > are approvals so complicated and lengthy?
>>> > If you have any fixes or suggestions, please let me know. I would >>> > like to >>> > put this server into production soon, but it is quickly becoming a >>> > major >>> > headache, having to devote an entire business day just for approvals >>> > to >>> > happen (or not happen, as has been the case lately).
>>> > Thanks,
>>> > Bohdan
>>> > "Rajiv Poonamalli [MSFT]" wrote:
>>> >> We have identified a few performance issues with update approval, >>> >> especially >>> >> when multiple updates are chosen for approval or the server has many >>> >> target >>> >> groups.
>>> >> How many updates are you attempting to approve at a time? >>> >> How many target groups are present on this server? >>> >> What is your approval strategy? Could you cut-paste the approvals for >>> >> a >>> >> typical update in your WSUS server?
>>> >> Thanks.
>>> >> -- >>> >> Rajiv Poonamalli [MSFT] >>> >> Windows Server Update Services
>>> >> This posting is provided "AS IS" with no warranties, and confers no >>> >> rights
>>> >> > Every now and then, I get a "timeout expired" error message when >>> >> > trying >>> >> > to >>> >> > approve or reapprove selected updates. I usually try again and the >>> >> > approvals >>> >> > go through without a problem. For the past few days, however, I >>> >> > almost >>> >> > always get the error, sometimes on the first update I try to >>> >> > approve, >>> >> > sometimes some 20 updates in. The text of the message is:
>>> >> > "Windows Server Update Services error -- Web Page Dialog
>>> >> > Windows Server Update Services encountered an error.
>>> >> > Timeout expired. The timeout period elapsed prior to completion of >>> >> > the >>> >> > operation or the server is not responding.
>>> >> > [Show Details] [Close]"
>>> >> > When I press "Show Details", the following information is given:
>>> >> > "System.Data.SqlClient.SqlException: Timeout expired. The timeout >>> >> > period >>> >> > elapsed prior to completion of the operation or the server is not >>> >> > responding. >>> >> > at >>> >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException >>> >> > e) >>> >> > at >>> >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() >>> >> > at >>> >> > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection >>> >> > connection) >>> >> > at >>> >> > Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String >>> >> > spName, DBParameterCollection args, IExecuteSPHandler handler) >>> >> > at >>> >> > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g >>> >> > spName, DBParameterCollection args, Type resultType) >>> >> > at >>> >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid >>> >> > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid >>> >> > targetGroupId, >>> >> > String adminName, DateTime deadline, Boolean isAssigned, DateTime >>> >> > goLiveTime, >>> >> > Int32 downloadPriority, Guid deploymentGuid, Boolean >>> >> > translateSqlException) >>> >> > at >>> >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId >>> >> > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime >>> >> > deadline, >>> >> > String adminName) >>> >> > at >>> >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >>> >> > action, IComputerTargetGroup targetGroup, DateTime deadline) >>> >> > at >>> >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >>> >> > action, IComputerTargetGroup targetGroup) >>> >> > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) >>> >> > at Administration.Updates.UpdateXPost.Page_Load(Object sender, >>> >> > EventArgs >>> >> > e)
Saying that approving that many updates is not helpfull at all!
I have a new wsus server with new groups and need to approve/detect for 5 groups to make the new server work, and yes, I've wasted a whole day as well trying to get the damm thing to approve the updates.
Please reply to News Groups, not my email, as its got a full mailbox of spam, I only use the address for posting to NG's
Could the microsoft chap post the sql code to the newsgroup so everyone having the problem can try to get it working, and out of interest what testing was done with msde and say 5 or 6 groups, or is this the normal M$ "lets release untested untried software, and waste peoples time"?
This is exactly my concern as well. While I agree that the day-to-day operation of WSUS should not require approving or reapproving hundreds of updates at a time, the initial setup should be as troublefree as possible, and this includes being able to put WSUS into production quickly. The only realistic way to do this would be to do "batch" approvals to establish a baseline of sorts, and then to worry only about new updates as they become available. So far, WSUS has been a major disappointment in this respect.
As far as the updates I was approving, Lawrence, like I said, I get the timeout error regardless of how many updates I choose to approve. Yesterday evening I tried approving just one update and always kept receiving the timeout error after some 75 seconds of attempted approval. This was definitely not the case last week, when I first set up the server; back then, each approval took a maximum of 30 seconds, irrespective of how many updates at a time were being approved.
I would like to know what is going on, because at this rate, rolling WSUS out to our clients will inevitably result in more headaches than it's worth.
Bohdan
"ServerAdmin999" <gordonb...@totalise.co.uk> wrote in message
> Saying that approving that many updates is not helpfull at all!
> I have a new wsus server with new groups and need to approve/detect for > 5 groups to make the new server work, and yes, I've wasted a whole day > as well trying to get the damm thing to approve the updates.
> Please reply to News Groups, not my email, as its got a full mailbox of > spam, I only use the address for posting to NG's
> Could the microsoft chap post the sql code to the newsgroup so everyone > having the problem can try to get it working, and out of interest what > testing was done with msde and say 5 or 6 groups, or is this the normal > M$ "lets release untested untried software, and waste peoples time"?
ServerAdmin999 wrote: > Saying that approving that many updates is not helpfull at all!
> I have a new wsus server with new groups and need to approve/detect for > 5 groups to make the new server work, and yes, I've wasted a whole day > as well trying to get the damm thing to approve the updates.
> Please reply to News Groups, not my email, as its got a full mailbox of > spam, I only use the address for posting to NG's
> Could the microsoft chap post the sql code to the newsgroup so everyone > having the problem can try to get it working, and out of interest what > testing was done with msde and say 5 or 6 groups, or is this the normal > M$ "lets release untested untried software, and waste peoples time"?
Hi,
Content of addDeploymentIndex.sql:
--------------------8<---------------------- USE SUSDB GO BEGIN TRAN IF NOT EXISTS (SELECT * FROM sysindexes where name='nc7DeploymentRevision') BEGIN CREATE NONCLUSTERED INDEX nc7DeploymentRevision ON dbo.tbDeployment(RevisionID, TargetGroupID, ActionID) END COMMIT TRAN GO --------------------8<----------------------
Note that the text starting with "CREATE NONCLUSTERED " between the BEGIN ... END block needs to be one single long line, it will wrap over two lines in this post.
I don't have a clue what that sql code actually did, but it damm well did the trick, I was 1/2 way through trying to approve them again (about 90 secs/approval) and as soon as that script finished, its dropped to about 5 secs/approval (didn't even have to restart the approval process)
Can you please tell me how you ran the sql code? I followed the steps given to me by Rajiv earlier and got an error message. The sql file itself though is the same version that Torgeir recently posted. Did you run the code differently from Rajiv's instructions?
Thanks,
Bohdan
"ServerAdmin999" <gordonb...@totalise.co.uk> wrote in message
> I don't have a clue what that sql code actually did, but it damm well > did the trick, I was 1/2 way through trying to approve them again > (about 90 secs/approval) and as soon as that script finished, its > dropped to about 5 secs/approval (didn't even have to restart the > approval process)
Bohdan, Based on your error message, it seems that the WSUS server database (SUSDB) is not on the default SQL server instance on the machine. It is probably on a named instance. Look at the following registry key to find out which SQL server/MSDE server you have to run the command at.
> I attempted to follow your advice by RDPing into the server and performing > the steps you outlined. First, I found that the osql utility is actually > in the osql subdirectory of Tools. I copied the sql file into the > directory with the osql utility and ran the command exactly as you > specified. I received an error, which I am pasting below. The name of my > WSUS server is NY1221WSUS2K.
> "C:\Program Files\Update Services\Tools\osql>osql -E -S > NY1221WSUS2K -n -b -i add > DeploymentIndex.sql > Msg 911, Level 16, State 1, Server NY1221WSUS2K, Line 1 > Could not locate entry in sysdatabases for database 'SUSDB'. No entry > found > with that name. Make sure that the name is entered correctly."
> Am I doing something wrong, or is this not supported via RDP? Please > advise.
> Thanks,
> Bohdan
> "Rajiv Poonamalli [MSFT]" <raj...@online.microsoft.com> wrote in message > news:eW1EjW5zFHA.612@TK2MSFTNGP10.phx.gbl... >> Bohdan, >> We are currently in the process of addressing some of the performance >> issues in this area. The steps below would fix part of the performance >> problems you are facing. Please try these on your server and let us know >> if it solves the timeout issues.
>> 1) Save the attached file to disk on the WSUS server >> 2) As administrator, run the following command. >> osql -E -S <MSDEServerName> -n -b -i addDeploymentIndex.sql
>> The osql utility can be found in under the Program Files\Update >> Services\Tools folder.
>> -- >> Rajiv Poonamalli [MSFT] >> Windows Server Update Services
>> This posting is provided "AS IS" with no warranties, and confers no >> rights
>> "Bohdan" <Boh...@discussions.microsoft.com> wrote in message >> news:85813053-D2D6-4FBA-AB4E-70D83C6BFC8D@microsoft.com... >>> MSDE, with whatever patches and updates are currently available. The >>> WSUS >>> server is Windows 2000 Standard, with SP4.
>>> "David Hennessey (MSFT)" wrote:
>>>> Are you running Full SQL or WMSDE?
>>>> -- >>>> This posting is provided "As Is" with no warranties, and confers no >>>> rights. >>>> Use of included script samples are subject to the terms specified at >>>> http://www.microsoft.com/info/cpyright.htm
>>>> > The WSUS environment here is still in an experimental stage, so I am >>>> > changing the target groups and approvals fairly often before I settle >>>> > down >>>> > on >>>> > any one particular strategy. However, the strategy I have been using >>>> > fairly >>>> > consistently for the past few days and will probably settle on is as >>>> > follows:
>>>> > 1. All Computers. This group is allowed to detect all possible >>>> > updates >>>> > but >>>> > not install. >>>> > 2. Unassigned Computers - Same as All Computers. >>>> > 3. Force - This is an experimental group which forces an installation >>>> > of >>>> > all >>>> > possible updates by specifying a deadline of 12:00AM, 10/01/2005. >>>> > 4. SP2 - This is the group to which computers are slowly being added >>>> > through >>>> > client-side targeting and a dedicated WSUS OU. Initially, this group >>>> > denied >>>> > all updates except for XP SP2, which it installed based on the GP >>>> > schedule.
>>>> > I now want the SP2 group to approve the installation of all possible >>>> > critical updates in addition to SP2 and so am trying to approve some >>>> > 550 >>>> > or >>>> > so updates according to this strategy. Sometimes I receive the >>>> > timeout >>>> > error >>>> > after the first attempted approval, sometimes more get approved >>>> > before the >>>> > timeout. Today, WSUS managed to approve some 220 updates before >>>> > timing >>>> > out.
>>>> > Additionally, it seems that every time I change approvals, the >>>> > approval >>>> > process takes longer and longer. The first time I approved updates, >>>> > each >>>> > approval took some 10 seconds. Today, each approval that manages to >>>> > go >>>> > through takes between 70 and 90 seconds EACH. Why this performance >>>> > hit? >>>> > Why >>>> > are approvals so complicated and lengthy?
>>>> > If you have any fixes or suggestions, please let me know. I would >>>> > like to >>>> > put this server into production soon, but it is quickly becoming a >>>> > major >>>> > headache, having to devote an entire business day just for approvals >>>> > to >>>> > happen (or not happen, as has been the case lately).
>>>> > Thanks,
>>>> > Bohdan
>>>> > "Rajiv Poonamalli [MSFT]" wrote:
>>>> >> We have identified a few performance issues with update approval, >>>> >> especially >>>> >> when multiple updates are chosen for approval or the server has many >>>> >> target >>>> >> groups.
>>>> >> How many updates are you attempting to approve at a time? >>>> >> How many target groups are present on this server? >>>> >> What is your approval strategy? Could you cut-paste the approvals >>>> >> for a >>>> >> typical update in your WSUS server?
>>>> >> Thanks.
>>>> >> -- >>>> >> Rajiv Poonamalli [MSFT] >>>> >> Windows Server Update Services
>>>> >> This posting is provided "AS IS" with no warranties, and confers no >>>> >> rights
>>>> >> > Every now and then, I get a "timeout expired" error message when >>>> >> > trying >>>> >> > to >>>> >> > approve or reapprove selected updates. I usually try again and >>>> >> > the >>>> >> > approvals >>>> >> > go through without a problem. For the past few days, however, I >>>> >> > almost >>>> >> > always get the error, sometimes on the first update I try to >>>> >> > approve, >>>> >> > sometimes some 20 updates in. The text of the message is:
>>>> >> > "Windows Server Update Services error -- Web Page Dialog
>>>> >> > Windows Server Update Services encountered an error.
>>>> >> > Timeout expired. The timeout period elapsed prior to completion >>>> >> > of the >>>> >> > operation or the server is not responding.
>>>> >> > [Show Details] [Close]"
>>>> >> > When I press "Show Details", the following information is given:
>>>> >> > "System.Data.SqlClient.SqlException: Timeout expired. The timeout >>>> >> > period >>>> >> > elapsed prior to completion of the operation or the server is not >>>> >> > responding. >>>> >> > at >>>> >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException >>>> >> > e) >>>> >> > at >>>> >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection >>>> >> > connection) >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String >>>> >> > spName, DBParameterCollection args, IExecuteSPHandler handler) >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g >>>> >> > spName, DBParameterCollection args, Type resultType) >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(Guid >>>> >> > updateId, Int32 revisionNumber, Int32 deploymentAction, Guid >>>> >> > targetGroupId, >>>> >> > String adminName, DateTime deadline, Boolean isAssigned, DateTime >>>> >> > goLiveTime, >>>> >> > Int32 downloadPriority, Guid deploymentGuid, Boolean >>>> >> > translateSqlException) >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccess.ExecuteSPD eployUpdate(UpdateRevisionId >>>> >> > updateId, Int32 deploymentAction, Guid targetGroupId, DateTime >>>> >> > deadline, >>>> >> > String adminName) >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >>>> >> > action, IComputerTargetGroup targetGroup, DateTime deadline) >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.BaseApi.Update.Approve(UpdateApprovalActi on >>>> >> > action, IComputerTargetGroup targetGroup) >>>> >> > at Administration.Updates.UpdateProxy.Deploy(String xpostXml) >>>> >> > at Administration.Updates.UpdateXPost.Page_Load(Object sender, >>>> >> > EventArgs >>>> >> > e)
>>>> >> > at >>>> >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnectio ns(SqlException >>>> >> > e) >>>> >> > at >>>> >> > Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader() >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.SingleResultSetSPHandler.ExecuteStoredPro cedure(DBConnection >>>> >> > connection) >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.GenericDataAccess.ExecuteSP(String >>>> >> > spName, DBParameterCollection args, IExecuteSPHandler handler) >>>> >> > at >>>> >> > Microsoft.UpdateServices.Internal.DataAccess.ExecuteSPSingleResultSet(Strin g >>>> >> > spName, DBParameterCollection args, Type resultType) >>>> >> > at
Bohdan, make sure you know the 'name' of the MSDE instance where the SUSDB lives. As Rajiv mentioned in his post above the registry key will show the instance name of MSDE that WSUS is using. Specifying that in the -S parameter to OSQL should allow it to run against the db successfully.
As for what this does, we found that the reason the approvals were taking so long was the query plan that SQL was choosing when we delete approvals in the DB (of course, the reason we are deleting approvals at all is another story, but that is something we'll try to fix in SP1) was quite inefficient because one of the pieces of data we were querying on wasn't indexed properly.
Creation of that index allows SQL to choose a much more performant query plan and in our tests reduced the deployment delete time 'significantly'.
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Bohdan" <Boh...@discussions.microsoft.com> wrote in message
> Can you please tell me how you ran the sql code? I followed the steps > given to me by Rajiv earlier and got an error message. The sql file > itself though is the same version that Torgeir recently posted. Did you > run the code differently from Rajiv's instructions?
>> I don't have a clue what that sql code actually did, but it damm well >> did the trick, I was 1/2 way through trying to approve them again >> (about 90 secs/approval) and as soon as that script finished, its >> dropped to about 5 secs/approval (didn't even have to restart the >> approval process)
David.. is this index enhancement recommended for any particular 'environment' of deployment, i.e. a certain database file size, certain number of clients, certain number of metadata records... or is this still being offered only on an 'as needed' basis?
> Bohdan, make sure you know the 'name' of the MSDE instance where the SUSDB > lives. As Rajiv mentioned in his post above the registry key will show the > instance name of MSDE that WSUS is using. Specifying that in the -S > parameter to OSQL should allow it to run against the db successfully.
> As for what this does, we found that the reason the approvals were taking > so long was the query plan that SQL was choosing when we delete approvals > in the DB (of course, the reason we are deleting approvals at all is > another story, but that is something we'll try to fix in SP1) was quite > inefficient because one of the pieces of data we were querying on wasn't > indexed properly.
> Creation of that index allows SQL to choose a much more performant query > plan and in our tests reduced the deployment delete time 'significantly'.
> -- > This posting is provided "As Is" with no warranties, and confers no > rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm
>> Can you please tell me how you ran the sql code? I followed the steps >> given to me by Rajiv earlier and got an error message. The sql file >> itself though is the same version that Torgeir recently posted. Did you >> run the code differently from Rajiv's instructions?
>>> I don't have a clue what that sql code actually did, but it damm well >>> did the trick, I was 1/2 way through trying to approve them again >>> (about 90 secs/approval) and as soon as that script finished, its >>> dropped to about 5 secs/approval (didn't even have to restart the >>> approval process)
I just took the sql code, put it in a text file called addDeploymentIndex.sql in c:\program files\updateservices\tools\osql
I did have to adjust the line "CREATE NONCLUSTERED INDEX nc7DeploymentRevision ON dbo.tbDeployment(RevisionID, TargetGroupID, ActionID)"
as google had put it on two lines
I then ran the command
"osql -E -S susserver1 -n -b -i addDeploymentIndex.sql" (no quotes)
where susserver1 is the netbios name of our main sus server
Interestingly though, if I run the same command on our susserver2, (which is a replica of sus1) I get the same screen you get when you type "osql /?"
I checked the registry as Rajiv says, but the servername is listed as %computername% (which typing "set" at a command prompt shows as being susserver2) and the DB name is listed as SUSDB.
Interesting though, sus1 was a brand new install, SUS2 was an upgrade from the previous version of sus
As SUS2 synchronizes from SUS1, its not so bad that I cant get it to work on that one SUS2 does sometimes give the error Windows Server Update Services encountered an error. Object reference not set to an instance of an object
A reboot of the server fixes that, but not the osql error.
If WSUS is running on named instance -- which it /will/ be unless you've installed WSUS on a pre-existing installation of SQL Server 2000 SE/EE -- then you must include the name of the named instance in the -S parameter of the osql command, e.g.
otherwise it looks for the /default/ instance on that server.
Furthermore, a point not previously included, the named instance /will/ be "WSUS", as there's no way to complete the install with any other named instance of MSDE or WMSDE.
"ServerAdmin999" <gordonb...@totalise.co.uk> wrote in message
> where susserver1 is the netbios name of our main sus server
> Interestingly though, if I run the same command on our susserver2, > (which is a replica of sus1) I get the same screen you get when you > type "osql /?"
> I checked the registry as Rajiv says, but the servername is listed as > %computername% (which typing "set" at a command prompt shows as being > susserver2) and the DB name is listed as SUSDB.
> Interesting though, sus1 was a brand new install, SUS2 was an upgrade > from the previous version of sus
> As SUS2 synchronizes from SUS1, its not so bad that I cant get it to > work on that one > SUS2 does sometimes give the error > Windows Server Update Services encountered an error. > Object reference not set to an instance of an object
> A reboot of the server fixes that, but not the osql error.
When osql returns the help text (same as /?) it means something in the command line was incorrect.
Generally when I have this problem I just manually type the command and make sure of the 'case' used in the paramters. It is case sensitive.
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"ServerAdmin999" <gordonb...@totalise.co.uk> wrote in message
> where susserver1 is the netbios name of our main sus server
> Interestingly though, if I run the same command on our susserver2, > (which is a replica of sus1) I get the same screen you get when you > type "osql /?"
> I checked the registry as Rajiv says, but the servername is listed as > %computername% (which typing "set" at a command prompt shows as being > susserver2) and the DB name is listed as SUSDB.
> Interesting though, sus1 was a brand new install, SUS2 was an upgrade > from the previous version of sus
> As SUS2 synchronizes from SUS1, its not so bad that I cant get it to > work on that one > SUS2 does sometimes give the error > Windows Server Update Services encountered an error. > Object reference not set to an instance of an object
> A reboot of the server fixes that, but not the osql error.
It can be applied for any WSUS environment, but it hasn't been widely released as of yet. It is something we are looking into, but no firm ETA.
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
> David.. is this index enhancement recommended for any particular > 'environment' of deployment, i.e. a certain database file size, certain > number of clients, certain number of metadata records... or is this still > being offered only on an 'as needed' basis?
> "David Hennessey (MSFT)" <david...@online.microsoft.com> wrote in message > news:OazSyvE0FHA.2072@TK2MSFTNGP14.phx.gbl... >> Bohdan, make sure you know the 'name' of the MSDE instance where the >> SUSDB lives. As Rajiv mentioned in his post above the registry key will >> show the instance name of MSDE that WSUS is using. Specifying that in >> the -S parameter to OSQL should allow it to run against the db >> successfully.
>> As for what this does, we found that the reason the approvals were taking >> so long was the query plan that SQL was choosing when we delete approvals >> in the DB (of course, the reason we are deleting approvals at all is >> another story, but that is something we'll try to fix in SP1) was quite >> inefficient because one of the pieces of data we were querying on wasn't >> indexed properly.
>> Creation of that index allows SQL to choose a much more performant query >> plan and in our tests reduced the deployment delete time 'significantly'.
>> -- >> This posting is provided "As Is" with no warranties, and confers no >> rights. >> Use of included script samples are subject to the terms specified at >> http://www.microsoft.com/info/cpyright.htm
>>> Can you please tell me how you ran the sql code? I followed the steps >>> given to me by Rajiv earlier and got an error message. The sql file >>> itself though is the same version that Torgeir recently posted. Did you >>> run the code differently from Rajiv's instructions?
>>>> I don't have a clue what that sql code actually did, but it damm well >>>> did the trick, I was 1/2 way through trying to approve them again >>>> (about 90 secs/approval) and as soon as that script finished, its >>>> dropped to about 5 secs/approval (didn't even have to restart the >>>> approval process)
|
