Windows server update services configuration wizard

When I run the windows server updates services configuration wizard I get the
following error when you click start connection on the connect to upstream
server page:

The synchronization with the upstream server or microsoft update was canceled

Has anyone had this error before?

I am using a proxy server with the exact same setting as windows internet
explorer.

Thanks for any help given.
--
Mack

"Mack" <Mack@discussions.microsoft.com> wrote in message
news:EF802B31-9EC6-4F84-ACD6-43E7EF0DD633@microsoft.com...
> When I run the windows server updates services configuration wizard I get
> the
> following error when you click start connection on the connect to upstream
> server page:
>
> The synchronization with the upstream server or microsoft update was
> canceled
>
> Has anyone had this error before?

Quite often when the proxy server or firewall is interfering with the
process.


> I am using a proxy server with the exact same setting as windows internet
> explorer.

However, WSUS/BITS use WinHTTP not the IE protocols, so it could be that
your WinHTTP proxy client configuration is incorrect.

[a] Check the WSUS Server to ensure the Options | Proxy Configuration are
set correctly.
[b] Run the Client Diagnostic Tool, or proxycfg.exe, to ensure the WinHTTP
proxy settings are set correctly. If not, and you're sure the IE settings
are correct, run 'proxycfg -u' to clone the IE settings into WinHTTP.


--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/pr...2-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

Lawrence

Checked the proxy setting as suggested and they are set at should using the
proxycfg.exe -u

Found this error in the WSUS log:

2007-07-20 14:37:08.753
UTC Error WsusService.3 ReportingDatabaseAccess.AddReportingEventBatchToDa tabase Error
occurred while writing events to the database. Exception:
System.UnauthorizedAccessException: Access to the temp directory is denied.
Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is running
does not have sufficient permission to access the temp directory. CodeDom
will use the user account the process is using to do the compilation, so if
the user doesnt have access to system temp directory, you will not be able to
compile. Use Path.GetTempPath() API to find out the temp directory location.

I have checked the access to the windows temp directory and even set it to
everyone, however I still get this error message when I try to synch.

Any futher suggestions would be helpful and appreciated.

Thanks

--
Mack


"Lawrence Garvin (MVP)" wrote:

> "Mack" <Mack@discussions.microsoft.com> wrote in message
> news:EF802B31-9EC6-4F84-ACD6-43E7EF0DD633@microsoft.com...
> > When I run the windows server updates services configuration wizard I get
> > the
> > following error when you click start connection on the connect to upstream
> > server page:
> >
> > The synchronization with the upstream server or microsoft update was
> > canceled
> >
> > Has anyone had this error before?
>
> Quite often when the proxy server or firewall is interfering with the
> process.
>
>
> > I am using a proxy server with the exact same setting as windows internet
> > explorer.
>
> However, WSUS/BITS use WinHTTP not the IE protocols, so it could be that
> your WinHTTP proxy client configuration is incorrect.
>
> [a] Check the WSUS Server to ensure the Options | Proxy Configuration are
> set correctly.
> [b] Run the Client Diagnostic Tool, or proxycfg.exe, to ensure the WinHTTP
> proxy settings are set correctly. If not, and you're sure the IE settings
> are correct, run 'proxycfg -u' to clone the IE settings into WinHTTP.
>
>
> --
> Lawrence Garvin, M.S., MCTS, MCP
> Independent WSUS Evangelist
> MVP-Software Distribution (2005-2007)
> https://mvp.support.microsoft.com/pr...2-D095EB07B36E
>
> Everything you need for WSUS is at
> http://www.microsoft.com/wsus
>
> And, almost everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>

Mack schrieb:

> 2007-07-20 14:37:08.753
> UTC Error WsusService.3 ReportingDatabaseAccess.AddReportingEventBatchToDa tabase Error
> occurred while writing events to the database. Exception:
> System.UnauthorizedAccessException: Access to the temp directory is denied.
> Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is running
> does not have sufficient permission to access the temp directory. CodeDom
> will use the user account the process is using to do the compilation, so if
> the user doesnt have access to system temp directory, you will not be able to
> compile. Use Path.GetTempPath() API to find out the temp directory location.
>
> I have checked the access to the windows temp directory and even set it to
> everyone, however I still get this error message when I try to synch.

Give 'NT AUTHORITY\NETWORK SERVICE' Read Rights to the Temp Directory.

Winfried
--
http://www.microsoft.com/germany/win...s/default.mspx
http://www.wsuswiki.com/Home

Winfried

The network service does have access to the temp directory, however I still
get this error message:

2007-07-20 15:07:43.646
UTC Info WsusService.27 EventLogEventReporter.ReportEvent EventId=386,Type=Error,Category=Synchronization,Me ssage=Synchronization
failed. Reason: Access to the temp directory is denied. Identity 'NT
AUTHORITY\NETWORK SERVICE' under which XmlSerializer is running does not have
sufficient permission to access the temp directory. CodeDom will use the
user account the process is using to do the compilation, so if the user
doesnt have access to system temp directory, you will not be able to compile.
Use Path.GetTempPath() API to find out the temp directory location..
2007-07-20 15:07:43.646
UTC Error WsusService.27 ReportingDatabaseAccess.AddReportingEventBatchToDa tabase Error
occurred while writing events to the database. Exception:
System.UnauthorizedAccessException: Access to the temp directory is denied.
Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is running
does not have sufficient permission to access the temp directory. CodeDom
will use the user account the process is using to do the compilation, so if
the user doesnt have access to system temp directory, you will not be able to
compile. Use Path.GetTempPath() API to find out the temp directory location.

When it refers to the temp directory, is it the temp system under system
properties?

Thanks

--
Mack


"Winfried Sonntag [MVP]" wrote:

> Mack schrieb:
>
> > 2007-07-20 14:37:08.753
> > UTC Error WsusService.3 ReportingDatabaseAccess.AddReportingEventBatchToDa tabase Error
> > occurred while writing events to the database. Exception:
> > System.UnauthorizedAccessException: Access to the temp directory is denied.
> > Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is running
> > does not have sufficient permission to access the temp directory. CodeDom
> > will use the user account the process is using to do the compilation, so if
> > the user doesnt have access to system temp directory, you will not be able to
> > compile. Use Path.GetTempPath() API to find out the temp directory location.
> >
> > I have checked the access to the windows temp directory and even set it to
> > everyone, however I still get this error message when I try to synch.
>
> Give 'NT AUTHORITY\NETWORK SERVICE' Read Rights to the Temp Directory.
>
> Winfried
> --
> http://www.microsoft.com/germany/win...s/default.mspx
> http://www.wsuswiki.com/Home
>

"Mack" <Mack@discussions.microsoft.com> wrote in message
news:0CA13C77-944B-4178-AD16-A2ED77AD9BBC@microsoft.com...

> Found this error in the WSUS log:
>
> 2007-07-20 14:37:08.753
> UTC Error WsusService.3
> ReportingDatabaseAccess.AddReportingEventBatchToDa tabase Error
> occurred while writing events to the database. Exception:
> System.UnauthorizedAccessException: Access to the temp directory is
> denied.
> Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is
> running
> does not have sufficient permission to access the temp directory.

The NT AUTHORITY\Network Service account requires very specialized
permissions to the %windir%\temp directory, and I believe they should have
been set by the .NET Framework installer. However, if somebody has 'tweaked'
the permissions on the system, this could cause issues.

Here are the correct permissions for the "Network Service" account on
%windir%\temp:

Permissions are not inherited from the parent.

For "This folder and subfolders", the account requires:
Traverse Files/ Execute Files
List Folder / Read Data
Read Attributes
Delete
Read Permissions

For "Files only"
List Folder / Read Data
Delete

Granting the generic READ permission to the "Network Service" account is not
a proper solution because the READ permission does not grant the "Delete"
permission, and it unnecessarily grants "Read Extended Attributes" on the
folder and subfolders, and even more critically, it grants "Execute Files"
on the files in those folders and subfolders. In essence you create a
security hole on your machine by giving a network-enabled account execute
permissions to files it should not have execute permissions for. It also
doesn't have the ability to remove files from the %temp% folder when it's
done with them.




--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/pr...2-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

Lawrence

I have set the security as discussed however the problem still exsists.

Is there anyway to tell what the directory it's referring to in the log?

Well, I think I will leave it until monday now, off to do some hill walking
in the Nevis range Scotland.

Wish me luck.

Thanks for the help

--
Mack


"Lawrence Garvin (MVP)" wrote:

> "Mack" <Mack@discussions.microsoft.com> wrote in message
> news:0CA13C77-944B-4178-AD16-A2ED77AD9BBC@microsoft.com...
>
> > Found this error in the WSUS log:
> >
> > 2007-07-20 14:37:08.753
> > UTC Error WsusService.3
> > ReportingDatabaseAccess.AddReportingEventBatchToDa tabase Error
> > occurred while writing events to the database. Exception:
> > System.UnauthorizedAccessException: Access to the temp directory is
> > denied.
> > Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is
> > running
> > does not have sufficient permission to access the temp directory.
>
> The NT AUTHORITY\Network Service account requires very specialized
> permissions to the %windir%\temp directory, and I believe they should have
> been set by the .NET Framework installer. However, if somebody has 'tweaked'
> the permissions on the system, this could cause issues.
>
> Here are the correct permissions for the "Network Service" account on
> %windir%\temp:
>
> Permissions are not inherited from the parent.
>
> For "This folder and subfolders", the account requires:
> Traverse Files/ Execute Files
> List Folder / Read Data
> Read Attributes
> Delete
> Read Permissions
>
> For "Files only"
> List Folder / Read Data
> Delete
>
> Granting the generic READ permission to the "Network Service" account is not
> a proper solution because the READ permission does not grant the "Delete"
> permission, and it unnecessarily grants "Read Extended Attributes" on the
> folder and subfolders, and even more critically, it grants "Execute Files"
> on the files in those folders and subfolders. In essence you create a
> security hole on your machine by giving a network-enabled account execute
> permissions to files it should not have execute permissions for. It also
> doesn't have the ability to remove files from the %temp% folder when it's
> done with them.
>
>
>
>
> --
> Lawrence Garvin, M.S., MCTS, MCP
> Independent WSUS Evangelist
> MVP-Software Distribution (2005-2007)
> https://mvp.support.microsoft.com/pr...2-D095EB07B36E
>
> Everything you need for WSUS is at
> http://www.microsoft.com/wsus
>
> And, almost everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>

Run Process Monitor (Procmon) and it can tell you what Access Denied errors
you are getting on what resources. Filter by (a) the process name and (b)
file system operations to narrow down what you are viewing.
http://www.microsoft.com/technet/sys...ssmonitor.mspx

>> In essence you create a
>> security hole on your machine by giving a network-enabled account execute
>> permissions to files it should not have execute permissions for.

I'm not sure why a "network-enabled" account is a bigger risk than a
non-network enabled account. All local accounts (the Users group) on the
system have "traverse folder/execute file" permission on files within
c:\windows\temp (well, they do on a couple of sample Windows Server 2003
boxes I checked).

Cheers
Ken


"Mack" <Mack@discussions.microsoft.com> wrote in message
news:0D0B0769-4DCE-4963-AEF0-844699C853DC@microsoft.com...
> Lawrence
>
> I have set the security as discussed however the problem still exsists.
>
> Is there anyway to tell what the directory it's referring to in the log?
>
> Well, I think I will leave it until monday now, off to do some hill
> walking
> in the Nevis range Scotland.
>
> Wish me luck.
>
> Thanks for the help
>
> --
> Mack
>
>
> "Lawrence Garvin (MVP)" wrote:
>
>> "Mack" <Mack@discussions.microsoft.com> wrote in message
>> news:0CA13C77-944B-4178-AD16-A2ED77AD9BBC@microsoft.com...
>>
>> > Found this error in the WSUS log:
>> >
>> > 2007-07-20 14:37:08.753
>> > UTC Error WsusService.3
>> > ReportingDatabaseAccess.AddReportingEventBatchToDa tabase Error
>> > occurred while writing events to the database. Exception:
>> > System.UnauthorizedAccessException: Access to the temp directory is
>> > denied.
>> > Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is
>> > running
>> > does not have sufficient permission to access the temp directory.
>>
>> The NT AUTHORITY\Network Service account requires very specialized
>> permissions to the %windir%\temp directory, and I believe they should
>> have
>> been set by the .NET Framework installer. However, if somebody has
>> 'tweaked'
>> the permissions on the system, this could cause issues.
>>
>> Here are the correct permissions for the "Network Service" account on
>> %windir%\temp:
>>
>> Permissions are not inherited from the parent.
>>
>> For "This folder and subfolders", the account requires:
>> Traverse Files/ Execute Files
>> List Folder / Read Data
>> Read Attributes
>> Delete
>> Read Permissions
>>
>> For "Files only"
>> List Folder / Read Data
>> Delete
>>
>> Granting the generic READ permission to the "Network Service" account is
>> not
>> a proper solution because the READ permission does not grant the "Delete"
>> permission, and it unnecessarily grants "Read Extended Attributes" on the
>> folder and subfolders, and even more critically, it grants "Execute
>> Files"
>> on the files in those folders and subfolders. In essence you create a
>> security hole on your machine by giving a network-enabled account execute
>> permissions to files it should not have execute permissions for. It also
>> doesn't have the ability to remove files from the %temp% folder when it's
>> done with them.
>>
>>
>>
>>
>> --
>> Lawrence Garvin, M.S., MCTS, MCP
>> Independent WSUS Evangelist
>> MVP-Software Distribution (2005-2007)
>> https://mvp.support.microsoft.com/pr...2-D095EB07B36E
>>
>> Everything you need for WSUS is at
>> http://www.microsoft.com/wsus
>>
>> And, almost everything else is at
>> http://wsusinfo.onsitechsolutions.com
>> .....
>>
>>
>>

Ken

Thanks for the pointers, tracked the issue down to a permissons issue on the
documents and setting directory.

Thanks to everyone else for your help.

Duncan
--
Mack


"Ken Schaefer" wrote:

> Run Process Monitor (Procmon) and it can tell you what Access Denied errors
> you are getting on what resources. Filter by (a) the process name and (b)
> file system operations to narrow down what you are viewing.
> http://www.microsoft.com/technet/sys...ssmonitor.mspx
>
> >> In essence you create a
> >> security hole on your machine by giving a network-enabled account execute
> >> permissions to files it should not have execute permissions for.
>
> I'm not sure why a "network-enabled" account is a bigger risk than a
> non-network enabled account. All local accounts (the Users group) on the
> system have "traverse folder/execute file" permission on files within
> c:\windows\temp (well, they do on a couple of sample Windows Server 2003
> boxes I checked).
>
> Cheers
> Ken
>
>
> "Mack" <Mack@discussions.microsoft.com> wrote in message
> news:0D0B0769-4DCE-4963-AEF0-844699C853DC@microsoft.com...
> > Lawrence
> >
> > I have set the security as discussed however the problem still exsists.
> >
> > Is there anyway to tell what the directory it's referring to in the log?
> >
> > Well, I think I will leave it until monday now, off to do some hill
> > walking
> > in the Nevis range Scotland.
> >
> > Wish me luck.
> >
> > Thanks for the help
> >
> > --
> > Mack
> >
> >
> > "Lawrence Garvin (MVP)" wrote:
> >
> >> "Mack" <Mack@discussions.microsoft.com> wrote in message
> >> news:0CA13C77-944B-4178-AD16-A2ED77AD9BBC@microsoft.com...
> >>
> >> > Found this error in the WSUS log:
> >> >
> >> > 2007-07-20 14:37:08.753
> >> > UTC Error WsusService.3
> >> > ReportingDatabaseAccess.AddReportingEventBatchToDa tabase Error
> >> > occurred while writing events to the database. Exception:
> >> > System.UnauthorizedAccessException: Access to the temp directory is
> >> > denied.
> >> > Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is
> >> > running
> >> > does not have sufficient permission to access the temp directory.
> >>
> >> The NT AUTHORITY\Network Service account requires very specialized
> >> permissions to the %windir%\temp directory, and I believe they should
> >> have
> >> been set by the .NET Framework installer. However, if somebody has
> >> 'tweaked'
> >> the permissions on the system, this could cause issues.
> >>
> >> Here are the correct permissions for the "Network Service" account on
> >> %windir%\temp:
> >>
> >> Permissions are not inherited from the parent.
> >>
> >> For "This folder and subfolders", the account requires:
> >> Traverse Files/ Execute Files
> >> List Folder / Read Data
> >> Read Attributes
> >> Delete
> >> Read Permissions
> >>
> >> For "Files only"
> >> List Folder / Read Data
> >> Delete
> >>
> >> Granting the generic READ permission to the "Network Service" account is
> >> not
> >> a proper solution because the READ permission does not grant the "Delete"
> >> permission, and it unnecessarily grants "Read Extended Attributes" on the
> >> folder and subfolders, and even more critically, it grants "Execute
> >> Files"
> >> on the files in those folders and subfolders. In essence you create a
> >> security hole on your machine by giving a network-enabled account execute
> >> permissions to files it should not have execute permissions for. It also
> >> doesn't have the ability to remove files from the %temp% folder when it's
> >> done with them.
> >>
> >>
> >>
> >>
> >> --
> >> Lawrence Garvin, M.S., MCTS, MCP
> >> Independent WSUS Evangelist
> >> MVP-Software Distribution (2005-2007)
> >> https://mvp.support.microsoft.com/pr...2-D095EB07B36E
> >>
> >> Everything you need for WSUS is at
> >> http://www.microsoft.com/wsus
> >>
> >> And, almost everything else is at
> >> http://wsusinfo.onsitechsolutions.com
> >> .....
> >>
> >>
> >>
>
>

"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:uw4qrBQzHHA.1168@TK2MSFTNGP02.phx.gbl...

>>> In essence you create a
>>> security hole on your machine by giving a network-enabled account
>>> execute
>>> permissions to files it should not have execute permissions for.
>
> I'm not sure why a "network-enabled" account is a bigger risk than a
> non-network enabled account.

Really!? Hmmmm....... :-\

--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/pr...2-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

"Lawrence Garvin (MVP)" <onsitech@community.nospam> wrote in message
news:%23flw5JWzHHA.4800@TK2MSFTNGP05.phx.gbl...
> "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
> news:uw4qrBQzHHA.1168@TK2MSFTNGP02.phx.gbl...
>
>>>> In essence you create a
>>>> security hole on your machine by giving a network-enabled account
>>>> execute
>>>> permissions to files it should not have execute permissions for.
>>
>> I'm not sure why a "network-enabled" account is a bigger risk than a
>> non-network enabled account.
>
> Really!? Hmmmm....... :-\

In terms of running an .exe locally, it wouldn't matter whether the account
was local or "network enabled" - they'd still run the .exe right?

In terms of connecting to other resources on the network (asuming you ran an
..exe and it tried to do something bad across the network)- you'd be
connecting as machinename$, which in most configurations I've seen isn't
permitted access to very much at all. So there's a risk there, but I don't
think it's a huge security hole. There are far worse issues in a lot of
environments (e.g. local administrator passwords are all the same - if a
local admin was to run that .exe then it could wreak havoc on the network as
the .exe would be able to use NTLM pass-through authentication to auth as
Administrator on all machines).

Cheers
Ken