Kerry Brown wrote:

Steve Foster [SBS MVP] wrote:
Kerry Brown wrote:


On XP clients, this utility simply fails for non-administrative
users. It's only because of UAC/LUA/etc on Vista that there's an
opportunity to enter administrative credentials and have the
utility do its' thing (which is to install Outlook if necessary,
configure IE, create entries in Network Places, etc.)

I know that's the reason why. I still feel it's a bug. I don't like
the way it works with XP and it's worse with Vista. It is a big
security flaw forcing everyone to be a local administrator and goes
against the grain of the new security model in Vista. It will be a
major problem when deploying Vista workstations in a SBS environment
if you don't want everyone to be local administrators. There will be
no end of the users complaining about the UAC prompt, asking what
they should do, what's the password, etc. At least with XP you could
work around it. The SBS group rather than the Vista group will have
to fix it. If I complain about it every chance I get hopefully
sooner or later it will get through to the right people.

I disagree with the idea that ordinary users should be granted
administrative privileges on the workstation they use - so I don't do
so.

I don't think we disagree here. I wholeheartedly agree that standard users
shouldn't have administrator privileges or access to a password that
grants this.

You're right, I wasn't disagreeing with you. Users as local administrators
without good reason is not a sensible thing to do. Heck, even Microsoft
have finally recognised this. g




It's trivial to eliminate the problem:

* rename the standard SBS logon script, and put an empty script in
its' place (keeps the wizards happy), or
* comment out the invocation of the client setup utlity, or
* change it like this (use your favourite user account with local
administrative privileges):

if not "%username%"=="Installer" goto exit
\\server\clients\setup\setup.exe /s server
exit


That's three ways to fix it off the top of my head.

I also agree it's pretty easy to get around the problem. My point is it
shouldn't be a problem in the first place. In a properly designed
client/server network once the client is joined to the network there
shouldn't be any need for users to ever have local administrator
privileges. Programs should be able to install for the user with user
privileges. Updates should be able to be pushed out by the server without
any interaction from the users. I know this is a ways off with Windows
based networks and SBS in particular but if we all complain loud enough
the wait for it to happen will be shorter :-)

It's going to happen - but it'll be a while - as it takes new releases or
major service packs for Microsoft to roll out significant changes to
applications.

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

This is also fixed if the logon script is executed from a Computer/startup
GPO instead.

"Steve Foster [SBS MVP]" wrote in message
...
Kerry Brown wrote:

Steve Foster [SBS MVP] wrote:
Kerry Brown wrote:


On XP clients, this utility simply fails for non-administrative
users. It's only because of UAC/LUA/etc on Vista that there's an
opportunity to enter administrative credentials and have the
utility do its' thing (which is to install Outlook if necessary,
configure IE, create entries in Network Places, etc.)

I know that's the reason why. I still feel it's a bug. I don't like
the way it works with XP and it's worse with Vista. It is a big
security flaw forcing everyone to be a local administrator and goes
against the grain of the new security model in Vista. It will be a
major problem when deploying Vista workstations in a SBS environment
if you don't want everyone to be local administrators. There will be
no end of the users complaining about the UAC prompt, asking what
they should do, what's the password, etc. At least with XP you could
work around it. The SBS group rather than the Vista group will have
to fix it. If I complain about it every chance I get hopefully
sooner or later it will get through to the right people.

I disagree with the idea that ordinary users should be granted
administrative privileges on the workstation they use - so I don't do
so.

I don't think we disagree here. I wholeheartedly agree that standard users
shouldn't have administrator privileges or access to a password that
grants this.

You're right, I wasn't disagreeing with you. Users as local administrators
without good reason is not a sensible thing to do. Heck, even Microsoft
have finally recognised this. g




It's trivial to eliminate the problem:

* rename the standard SBS logon script, and put an empty script in
its' place (keeps the wizards happy), or
* comment out the invocation of the client setup utlity, or
* change it like this (use your favourite user account with local
administrative privileges):

if not "%username%"=="Installer" goto exit
\\server\clients\setup\setup.exe /s server
exit


That's three ways to fix it off the top of my head.

I also agree it's pretty easy to get around the problem. My point is it
shouldn't be a problem in the first place. In a properly designed
client/server network once the client is joined to the network there
shouldn't be any need for users to ever have local administrator
privileges. Programs should be able to install for the user with user
privileges. Updates should be able to be pushed out by the server without
any interaction from the users. I know this is a ways off with Windows
based networks and SBS in particular but if we all complain loud enough
the wait for it to happen will be shorter :-)

It's going to happen - but it'll be a while - as it takes new releases or
major service packs for Microsoft to roll out significant changes to
applications.

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

John [MS] wrote:

This is also fixed if the logon script is executed from a Computer/startup
GPO instead.


Hmmm, not sure that's entirely safe.

* the client setup utility can be configured to allow interaction with the
user
* it applies some settings to the users' profile

I suspect neither of those aspects would work under the solution you're
suggesting (mind you, we'd lose the user-specific bits with an installer
account too).

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

John,

I am an SBS 2003 SP1 user and am also testing Vista RC1. I, too, could not
connect using the connectcomputer facility through IE7 until I enabled the
Administrator account, logged in as Administrator and re-ran connectcomputer.
That worked, but then I noticed the default SBS logon script would hang
awaiting UAC approval. So, I disabled UAC.

I know that circumvents most of the new security in Vista, but the hassle of
having to approve the logon script at each logon is too much.

I am also a consultant to the local county school district. We use logon
scripts - the good old fashioned kind - in each school. We have a few that
run as part of a GPO. If these won't run without the user having to
"approve" each one when logging into the network, UAC will disappear
immediately, I'm certain.

"John [MS]" wrote:

I've been tracking an issue regarding UAC breaking logon scripts and I
need Repro's/scripts/examples. From what I've seen if you have your script
in the User/Logon GPO it pops UAC on some operations such as installing
antivirus or executing remote monitoring clients, cancelling on the UAC
prevents the domain policy from being fulfiled.

In some cases I have seen that moving these scripts to the Computer/Startup
GPO fixes the problem. Anybody had issues with similar cases? Have a bug
that was closed By Design, Not Repro relating to this type of issue, chime
in. Windows 2003 SBS connection issues welcome too.

Thanks,

John
Microsoft Windows Beta Team

B. Getreu wrote:

John,

I am an SBS 2003 SP1 user and am also testing Vista RC1. I, too, could not
connect using the connectcomputer facility through IE7 until I enabled the
Administrator account, logged in as Administrator and re-ran
connectcomputer.
That worked, but then I noticed the default SBS logon script would hang
awaiting UAC approval. So, I disabled UAC.

I know that circumvents most of the new security in Vista, but the hassle
of
having to approve the logon script at each logon is too much.

I am also a consultant to the local county school district. We use logon
scripts - the good old fashioned kind - in each school. We have a few that
run as part of a GPO. If these won't run without the user having to
"approve" each one when logging into the network, UAC will disappear
immediately, I'm certain.

They will run, that's not an issue.

But if they attempt to do anything that requires administrative
privileges, UAC will kick in.

This is why the default SBS logon script generates a UAC warning - it
invokes an executable that requires administrative privileges to do its'
work.

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

Every one have tested SBS logon with RC2?

"John [MS]" wrote:

I've been tracking an issue regarding UAC breaking logon scripts and I
need Repro's/scripts/examples. From what I've seen if you have your script
in the User/Logon GPO it pops UAC on some operations such as installing
antivirus or executing remote monitoring clients, cancelling on the UAC
prevents the domain policy from being fulfiled.

In some cases I have seen that moving these scripts to the Computer/Startup
GPO fixes the problem. Anybody had issues with similar cases? Have a bug
that was closed By Design, Not Repro relating to this type of issue, chime
in. Windows 2003 SBS connection issues welcome too.

Thanks,

John
Microsoft Windows Beta Team

Attila wrote:

Every one have tested SBS logon with RC2?


It's still the same - the SBS client deployment application causes a UAC
prompt.

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.