Re: Client Installation Issues: SMS 2.0 SP5

From: Jeff Harbaugh [MSFT] (jeffharb_at_online.microsoft.com)
Date: 02/23/04 

Date: Mon, 23 Feb 2004 11:11:18 -0800

If I am understanding this correctly you are logged on locally and not as a
domain user? You should be logged is a domain user and make sure you have
access to the CAP that you are installing from if SMS 2003 if SMS 2.0 then
it would be the logon share. Also you can check the wnmanual.log to see what
errors are being reported. The design of SMSMAN in SMS 2003 is that it
cannot be run from a mapped location. It uses \\server\cap_XXX. If this does
not fix it please attach the wnmanual..log from the failed client. 

-- 
Thanks
Jeff Harbaugh [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
"Daniel Kerr" <dkerr@satx.rr.com> wrote in message
news:uwfOeEi%23DHA.2824@tk2msftngp13.phx.gbl...
> :/
>
> That was one of the first things I tried.  Lets say the account I use for
> the SMS Services is SMSAdmin.  That's set as member of administrators,
> domain admins, domain users...
>
> So here's the question.  Now that I have a TON of systems reported as
> assigned but not installed, what's the solution?
>
> The sms service account has domain admin rights.  I setup the Client
> Installation Account as what was listed above being our local admin
> account...
>
> I can tell you that after I added the local machine admin as was listed in
> one of the posts above, I more then doubled the number of installed PC's
> (per the web reporting dashboard).  Up from 169 to 399.  I'm happy with
> that, but there are still a lot more machines out there...  I am going to
> dig some more as they might have messed up and put a diff. password on
some
> of those, but any other idea's why prior to this, the client didn't want
to
> install?  Especially given the service account IS a domain admin account?
>
>
> "Travis Sweat (MSFT)" <travsw@microsoft.com> wrote in message
> news:OjBYHIA%23DHA.1392@tk2msftngp13.phx.gbl...
> > Ok, I'll try to explain a different way. This explanation is for SMS 2.0
> NOT
> > 2003. On the site server you have the SMSService account and you have a
> SMS
> > Remote Client Installation Account. When you run SMSMan.exe as a low
> rights
> > user (ie your Techs) SMSman realizes that you do not have rights to
> complete
> > the install. SMSMan then passes a CCR to the site server into the
CCM.box.
> > CCM then processes the CCR and attempts to push the client onto the low
> > rights system. If the SMS service account does not have admin level
rights
> > on the system it will fail to install. So you have 3 choices. Grant the
> > service account admin rights on every box, grant the service account
> domain
> > admin rights or Use the SMS Remote Client Installation Account.CCM will
> > first try the service account then fall back to the Remote Client
> > Installation Account. Grant that account domain admin rights and no one
> but
> > the creator has to know the password.
> > Hope that clears the fog. See the attachment.
> >
> > -- 
> > Travis Sweat [MSFT]
> > This posting is provided "AS IS" with no warranties, and confers no
rights
> > "Daniel Kerr" <dkerr@satx.rr.com> wrote in message
> > news:uwZtv2$9DHA.2480@TK2MSFTNGP12.phx.gbl...
> > > Actually, we are using SMSMan to install these...
> > >
> > > I connect to the install point, run SMSMan.  The only way SMS fully
> > installs
> > > is if I have local admin rights on the machine PLUS access to the
domain
> > (IE
> > > a user account).  If I'm logged in locally on the machine and run
this,
> > then
> > > it never fully finishes the install... Same if I log into the machine
as
> a
> > > domain user and try to run it (even a power user).  The only way for
me
> to
> > > get this to install right is to use a domain account that has local
> admin
> > > rights.  Given I'm not about to give my PC techs domain admin access
on
> > > their accounts, they now have to log into the machine as local admin,
> set
> > > their domain account w/ local admin rights, log out, log in using
their
> > > domain account, then install SMS.  Then it works sweet as cake...
> > >
> > >
> > > I am rather interested in this:
> > > [quote]
> > > As you said if you have local account which has admin rights on the
box,
> > > then you could do the following.
> > >
> > > In the push account list provide the account name as
> > > %MachineName%\<localaccountname>. You can add more than one account in
> the
> > > list.
> > > [/quote]
> > >
> > > I am assuming this is under the SMS Client remote install accounts...
> > I'll
> > > try to add all the local domain accounts to this...  I am guessing
using
> > > the:
> > > %MachineName% param will default to the machine name itself?
> > >
> > > "Travis Sweat (MSFT)" <travsw@microsoft.com> wrote in message
> > > news:uQmWY109DHA.3820@tk2msftngp13.phx.gbl...
> > > > SMSMan will also install a low rights user as long as the push
account
> > has
> > > > admin rights on the box.
> > > >
> > > > "Sourabh Guha (MSFT)" <sguha@microsoft.com> wrote in message
> > > > news:OL32hj09DHA.3292@TK2MSFTNGP11.phx.gbl...
> > > > > As you said if you have local account which has admin rights on
the
> > box,
> > > > > then you could do the following.
> > > > >
> > > > > In the push account list provide the account name as
> > > > > %MachineName%\<localaccountname>. You can add more than one
account
> in
> > > the
> > > > > list.
> > > > >
> > > > > Sourabh (MSFT)
> > > > > "Daniel Kerr" <dkerr@satx.rr.com> wrote in message
> > > > > news:uHVYXfz9DHA.568@TK2MSFTNGP09.phx.gbl...
> > > > > > Ok, here's the issue...
> > > > > >
> > > > > > Domain admin installs the client, and everything works fine.
> > > > > > Domain user who sets himself up as local admin on a PC works
fine.
> > > > > >
> > > > > > Where we run into issues w/ the client install is if we use the
> > local
> > > > > admin
> > > > > > account on the machine.  The client installs, SMS see's and
> assigns
> > it
> > > a
> > > > > > site (within SMS), but no site info gets put on the client and
> none
> > of
> > > > the
> > > > > > components install.  In the SMS Manager, you see that the client
> is
> > > > > > assigned, but reports as no installed site and no client
> installed.
> > > > > >
> > > > > > So, the question is.  Since our PC techs aren't given domain
admin
> > > > rights,
> > > > > > how can we best allow them to install the client and get it
hooked
> > in?
> > > > > The
> > > > > > boundaries are fine.  See, we setup a local admin account on
each
> > > > machine.
> > > > > > The PC tech's know that account.  So using a local PC account w/
> > admin
> > > > > > access, what should we change to get SMS to install right?  My
> guess
> > > is
> > > > > that
> > > > > > given it's a local machine account, it can't access the CAP.
> Would
> > > > adding
> > > > > > the everyone group as read only for the entire CAP share work?
> > > > > >
> > > > > > Oh, and FYI.  Even after network discoveries run, it still won't
> > > install
> > > > > the
> > > > > > components.  Is there a way to force the components to install
on
> a
> > > > > machine
> > > > > > that already has the SMS client done (no components)?
> > > > > >
> > > > > > Thanks for any advice/help you can give.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>

Relevant Pages

  • Re: Client Installation Issues: SMS 2.0 SP5
    ... Log on locally as LOCAL admin and install. ... Log on Locally as domain user who has LOCAL admin rights. ... The SMS Service account IS a domain admin ...
    (microsoft.public.sms.setup)
  • Re: New install, login not accepted
    ... install SPS. ... I got through the install following the steps in the Admin. ... a admin account, that account needs admin rights to SQL and the local box, ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Prevent users from installing software
    ... Just take them out of the admin group. ... If that user has admin rights, ... If your admins need to install software, just have them use the runas ... > as logging off and logging on as one of them to install the software, ...
    (microsoft.public.win2000.security)
  • Printer will only work in Admin Account
    ... > other programs I install, for that matter) show up on all ... > will only work in the Admin account. ... I then gave a user account Admin rights and it ...
    (microsoft.public.windowsxp.print_fax)
  • Re: Lost admin access to ADAM
    ... admins) as ADAM admin principal, as opposed to a specific user. ... use your domain account to connect (provided this account is a member of ... This posting is provided "AS IS" with no warranties, and confers no rights. ... If I install with my account (which has has local ...
    (microsoft.public.windows.server.active_directory)