Re: Duplicate GUID problem with newuid.exe package
- From: "Scott Brimley [MSFT]" <scottbr@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 30 Mar 2005 17:39:47 -0800
One last thought.
You could wrap this all in a SMS Installer package which could encapsulate
the EXE, copy it to a known location, execute it, then clean it up all in
one command.
--
Thanks
Scott Brimley [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
Additional Resources:
SMS 2.0 Resource Page:
http://www.microsoft.com/technet/prodtechnol/sms/sms2/default.mspx
SMS 2003 Resource Page:
http://www.microsoft.com/technet/prodtechnol/sms/sms2003/default.mspx
SMS 2003 Technical FAQ:
http://www.microsoft.com/technet/prodtechnol/sms/sms2003/techfaq/default.mspx
"Scott Brimley [MSFT]" <scottbr@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:...
> The link I posted points to a doc that has a sample batch file. It also
> references a problem in 2.0 where a command line with arguments is not
> parsed properly (235149 Simple Command Fails in Available Program Manager
> (APM).) so the command is not executed properly. The workaround is a
> batch file.
>
> Managing Duplicate Microsoft Systems Management Server Unique Identifiers
> http://www.microsoft.com/technet/prodtechnol/sms/sms2/optimize/dupid1.mspx
>
> Try running the following as a test.
> 1) Copy the EXE locally - you can create a package with a batch file to
> copy the file ( use the program properties to map a drive letter and use
> that drive letter in the batch file )
> 2) Create a batch file based on the article and try running it.
>
> If the test works make Program 2 dependant on program 1 and advertise
> program 2. This will force the download before the run and you will only
> have to manage one advertisment.
>
> If you wanted to be really fancy you could make a third that cleans up the
> EXE after all is said and done. The downside to this is if you have to
> run it a second time, the Dependant program will think that prog 1 has
> already run and will not try to run it a second time.
>
> --
> Thanks
>
> Scott Brimley [MSFT]
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> Additional Resources:
> SMS 2.0 Resource Page:
> http://www.microsoft.com/technet/prodtechnol/sms/sms2/default.mspx
> SMS 2003 Resource Page:
> http://www.microsoft.com/technet/prodtechnol/sms/sms2003/default.mspx
> SMS 2003 Technical FAQ:
> http://www.microsoft.com/technet/prodtechnol/sms/sms2003/techfaq/default.mspx
>
> "john" <john@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:70FD70D9-2AF2-4520-BEDB-6F8AE648E36B@xxxxxxxxxxxxxxxx
>> Originally I was but I always got an error when the batch file was trying
>> to
>> run. So it never worked properly. I am running the executable and
>> switches
>> right in the package command line.
>>
>> WHen I was using the batch file I simply put a batch file with the line
>> newuid.exe /s /allocate in the same source location as the executable.
>> When
>> watching a client try to run it a DOS window opened and closed quickly
>> with
>> an error that c:\windows\system32\newuid.exe wasn't a proper command or
>> something to that effect. It was basically looking for the exe locally
>> and
>> it wasn't there. So, I am not sure what I would need to add to the batch
>> to
>> make it run properly through the package. Any advice?
>>
>> "Scott Brimley [MSFT]" wrote:
>>
>>> Are you running newguid.exe from within a batch file?
>>>
>>> Managing Duplicate Microsoft Systems Management Server Unique
>>> Identifiers
>>> http://www.microsoft.com/technet/prodtechnol/sms/sms2/optimize/dupid1.mspx
>>>
>>> --
>>> Thanks
>>>
>>> Scott Brimley [MSFT]
>>>
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>>
>>> Additional Resources:
>>> SMS 2.0 Resource Page:
>>> http://www.microsoft.com/technet/prodtechnol/sms/sms2/default.mspx
>>> SMS 2003 Resource Page:
>>> http://www.microsoft.com/technet/prodtechnol/sms/sms2003/default.mspx
>>> SMS 2003 Technical FAQ:
>>> http://www.microsoft.com/technet/prodtechnol/sms/sms2003/techfaq/default.mspx
>>>
>>> "john" <john@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>>> news:6611577F-9893-482F-B882-E282C82B740D@xxxxxxxxxxxxxxxx
>>> > bump
>>> >
>>> > help
>>> >
>>> > "john" wrote:
>>> >
>>> >> To follow up, the method I used where I check the "Use Windows NT
>>> >> client
>>> >> > software installation account" box worked on a windows 2000 box in
>>> >> > my
>>> >> > test environment but fails with the 255 exit code on XP machines.
>>> >> > Unfortunately the rest of the company is XP, the 2K box was a
>>> >> > leftover
>>> >> > from the old days.....
>>> >>
>>> >> "john" wrote:
>>> >>
>>> >> > Hi, I have an SMS 2.0 SP5 system. I am trying to get a package
>>> >> > together that
>>> >> > will properly run the newuid.exe /s /allocate on the clients to
>>> >> > clean
>>> >> > up
>>> >> > dupes. I've created the proper queries and collection. All my end
>>> >> > users
>>> >> > have local PowerUser rights. The problems I am having are:
>>> >> >
>>> >> > - If I set the program to run with "user rights" and only when the
>>> >> > user
>>> >> > is
>>> >> > logged on, newuid.exe runs but it does not release the current
>>> >> > guid
>>> >> > due to
>>> >> > the lack of local administrator rights. The allocate switch run
>>> >> > properly and
>>> >> > it is able to access the SMS logon share and run smsboot1.exe but
>>> >> > since
>>> >> > it is
>>> >> > still holding the old GUID it does not get a new one.
>>> >> >
>>> >> > - If I set the package to run "with administrative rights" and only
>>> >> > when the
>>> >> > user is logged on, the newuid.exe run properly and the guid is
>>> >> > dropped,
>>> >> > but
>>> >> > since it is running with the local sms account rights it cannot
>>> >> > access
>>> >> > the
>>> >> > domain sms logon share to get a new GUID. So the client is left
>>> >> > without a
>>> >> > GUID running it this way.
>>> >> >
>>> >> > -Both of the above setups show as "completed" on the client, but
>>> >> > obviously
>>> >> > the results are not desired. Someone suggested setting the program
>>> >> > to
>>> >> > "run
>>> >> > when user is logged off" or "run whether a user is logged on or
>>> >> > off"
>>> >> > and
>>> >> > using administrative rights AND THEN checking the "Use Windows NT
>>> >> > client
>>> >> > software installation account" box. Thought being this would run
>>> >> > the
>>> >> > program
>>> >> > with the account defined in the software distribution setting of
>>> >> > component
>>> >> > configuration in the site settings. This is the domain account
>>> >> > smsservice
>>> >> > and should allow access to network resources other than the package
>>> >> > files on
>>> >> > the distribution point. This would allow the rights to run the
>>> >> > newuid.exe
>>> >> > successfully and the domain rights to run smsboot1.exe of the logon
>>> >> > share
>>> >> > successfully. Good thought right? Unfortunately this ended in the
>>> >> > advertisement "failing" with an exit code of 255.
>>> >> >
>>> >> > Can anyone help me or give me pointers to get these damn duplicates
>>> >> > cleaned
>>> >> > up? I am going NUTS!!!
>>>
>>>
>>>
>
>
.
- Follow-Ups:
- Re: Duplicate GUID problem with newuid.exe package
- From: Scott Brimley [MSFT]
- Re: Duplicate GUID problem with newuid.exe package
- Prev by Date: Re: Duplicate GUID problem with newuid.exe package
- Next by Date: Re: Duplicate GUID problem with newuid.exe package
- Previous by thread: Re: Duplicate GUID problem with newuid.exe package
- Next by thread: Re: Duplicate GUID problem with newuid.exe package
- Index(es):
Relevant Pages
|
