Web Service for OS Deployment - SCCM, Configuration Manager Current Branch

Onevinn Web Services exposes methods for adding and removing computers from Collections and AD Groups, retrieving group memberships (used for application installation during OSD) as well as several different methods to avoid known issues during deployment.

 
 
 
 
 
3.7 Star
(3)
1,025 times
Add to favorites
System Center
8/28/2017
E-mail Twitter del.icio.us Digg Facebook
Sign in to ask a question


  • Run Commandline as different User
    3 Posts | Last post September 05, 2017
    • Is there a way to start the Webservice during a TaskSequence without define a User / Password in configuration.ps1? I've tried to use the Option in "Run commandline" - "Run this step as the following account:" but until now with no success... 
    • I'm afraid not. Also, Run command line as the following account does not work in PE - as a hint why it failed. If you configure IIS to allow anonymous access and don't supply creds it might work but that sort of violates the concept, so I would not recommend it.
    • I agree, allowing anonymous access in IIS is really insecure. Instead you should put the username/password of the user that can issue commands to the web service in a clear text file and copy it over to the devices you intend to use this on. Nothing can go wrong then, you're perfectly safe!
  • Amazing tool!
    1 Posts | Last post September 05, 2017
    • So... instead of having a privileged account whose rights are strictly controlled to do just the function it requires and using multiple accounts (up to one per required function) where only a hand full of people are aware of the account's password (quite often actually meaning that the SCCM team won't even have access to that)...
      
      We now have the ability to setup a web service listening in for instructions and executing them with the credentials of a domain admin account (I mean, it's gotta have rights to do ALL possible tasks this supports, right? Which will grow in time I imagine, so let's be safe and just give it domain admin from the get go) and use a non-privileged account to send instructions to be executed. And let's give not only the SCCM team the credentials for this non-privileged account, but also let's write it down on a .settings file in clear text which we store on a network share all users can access and copy over to every computer we image during OSD.
      
      And this is safe not only because every single organization disabled F8 support in OSD, but also they *know* that a TS will never fail and leave stuff behind (such as ... say... a certain .settings file?) but also that there will be no power outage that could end up leaving the .settings file behind... or that no one will intentionally kill the power just at the right time... or that no one will bother to look through the DPs and happen across a .settings file...
      
      Hell why don't we just put huge posters on the wall with the credentials and hope no one happens to read it?
      
      Great, love it! Next step up in terms of security!