Not really a question, but...

Comments

12 comments

  • Jeff Longley

    Be very interested to hear how you've done this. I'm currently looking at how I can use PDQ with my MDT2013 deployment.

    0
    Comment actions Permalink
  • Shane Corellian

    Hi Paul,

    Sorry for missing this.

    If you are still interested in posting this we can make it happen. If you want you can email us the info and we will place it in the Knowledge Base under your name.

    Thanks for offering to do this.

    0
    Comment actions Permalink
  • Andrew Pasquetti

    Hi Paul,

    Been working on the same thing myself, haven't quite got there yet so interested to hear your approach.

    Cheers

    Andrew

    0
    Comment actions Permalink
  • Edward Gray

    Would love to see this posted.

    0
    Comment actions Permalink
  • Paul Thompson

    Sorry it's taken me so long to reply! 

    Too much work to do, not enough of me to go around!! But, i'm sure you all know how that goes, it's sort of a built-in part of IT I guess.

     

    Anyway... I didn't realize how vague my original post was, haha. 

    I'm going to try writing something up, but I'll give a quick breakdown of what I use. 

    Since the company I work for is too cheap to purchase SCCM, I had to come up with a free solution. I ended up going with FOG server. ( http://www.fogproject.org ) Work on FOG had stalled for a while, but back around Feb. 2014 I noticed that a few new people had started to breath life back into it, and over the past year, all I can say is WOW! They've made FOG into a really viable alternative to Ghost or even SCCM. Currently, I'm able to push out my configured/sysprepped Win7 image (around 19GB)  to an Optiplex 7010 in under 5 minutes! Including Windows setup, renaming, domain join, and a base push of software from Deploy (Flash, Java, Chrome, Reader), the entire system is at the login screen, ready to use, in under 15 minutes!

     

    That being said, the actual magic of the Zero touch, comes from a PowerShell script that I wrote, which you deploy to a client PC. Once the script runs on the client PC, it requests software packages from PDQ Deploy. 

     

    I'm fairly certain that this method could be easily adapted to SCCM. 

     

    Oh yea... @Shane - LOVE the beard man!! I could totally see it braided, like the Dwarves in WoW.

     

    0
    Comment actions Permalink
  • Jeff Longley

    Oooo Share that script!

    I've tried to work out a "pull" method for PDQ for a while

    0
    Comment actions Permalink
  • Paul Thompson

    It'll be a few minutes, I have to track it down in my "archive"... (old PC with a TON of junk files on it), plus I'm at work.

     

    But, i'll tell you, it's not pulling from PDQ... 

    0
    Comment actions Permalink
  • Paul Thompson

    Ok... Here is the magic!

    So, I used PowerShell's 'Invoke-Command' to send a deploy action to the server running PDQ Deploy.  The trickiest part of the whole thing, was getting the name of the of the computer that you wanted a package deployed to, sent to the Deploy server automatically. I'm calling in the "$remotecomputer" variable, which, before the actual Invoke-Command command is sent to the server, is populated with the name of the computer it is running on. Next, the "$remotecomputer" variable is added to the argument list of a ScriptBlock for Invoke-Command. I defined the parameter ($name) to allow for the variable in the ArgumentList to be dynamically added to the ScriptBlock by using "$name". So, as you see below, whatever workstation that you run the script on, will have its computer name added as the target of the command line deployment. 

     

    At first i was worried about having our domain admin password in plain text, but this script is only deployed as a FOG server Snap-In (deployment package for SCCM people). For FOG, Snap-Ins consist of an sfx executable, which for me, is just the .ps1 file and a .bat file that calls in PowerShell to run the .ps1 file, as for some reason, the Snap-In component can't execute .ps1 files alone. But, as I was saying, i'm not worried about putting my domain password into the .ps1, since the Snap-In deployment only runs at Windows startup, and upon failure or success, the Snap-In files are deleted. 

    Below, you see the script, in its entirety. 

    Areas in all CAPS are places that you need to fill in your specific info...

    ***NOTE*** - If you password has a $ in it, you have to include, what I believe is called, a delimiter. Basically, if your password was "AbC123$", you would have to enter it below as "AbC123'$" <--- Simply, you adding an apostrophe just before the $. :)

     

    $secpasswd = ConvertTo-SecureString "DOMAIN_ADMIN_PASSWORD" -AsPlainText -Force
    $creds = New-Object System.Management.Automation.PSCredential ("DOMAIN\DOMAIN_ADMIN",$secpasswd)
    $remotecomputer = Get-Content env:computername

    Invoke-Command -ComputerName SERVER_RUNNING_PDQ_DEPLOY -Credential $creds -ScriptBlock { param($name) & 'C:\Program Files (x86)\Admin Arsenal\PDQ Deploy\PDQDeploy.exe' Deploy -Package 'PDQ_DEPLOY_PACKAGE_NAME' -Target $name } -ArgumentList $remotecomputer

    0
    Comment actions Permalink
  • Paul Thompson

    Has anyone had a chance to try it out yet? I'm very interested to hear about it, as this is actually my very first PowerShell script! It's the culmination of about 2-3 days to research, lol. 

    0
    Comment actions Permalink
  • Andrew Pasquetti

    hey paul, the script works really well!

    After all that though i still couldn't get either my original method (which was really similar to what you are doing but using psexec/batch files) or this, running at firstboot - (i'm using smartdeploy, but FOG would have been my next choice. SmartDeploy has an option to include commands to run at firstboot, so i wanted to use that feature to run the script, but had all sorts of permissions issues)

    I found a workaround though - i included the scripts, and a scheduled task in my gold image that runs immediately at boot and launches the script using the system account (with domain credentials tucked inside the script as you have done to authenticate on the PDQ server)

    then i just added a couple of steps at the end of my PDQ deploy package to delete the scripts and the scheduled task. so now i can image the machine, deploy all my software and cleanup everything with a single touch. not quite as neat as using your FOG option but still working flawlessly.

    very awesome! thanks heap for sharing!!

    0
    Comment actions Permalink
  • Paul Williams

    Hi Paul,

    I just tested out the script and it works great.  I'm still working on getting it to run as part of my MDT task sequence but the script itself works fine.  Thanks for sharing!

    0
    Comment actions Permalink
  • Bob Henderson

    Paul-

     

    Just got this up and tested it on mine. I'm also a fog user, so question:

    You  have t his deployed as a snapin, correct? If so, care to go into how you made that? Just use the SFX maker or what? 

    If not, and you're u sing the scheduled task like listed  in other comment, does this fire off on boot before or after it joins the domain? last thing I'd want is it to start installing then poof gone.

    0
    Comment actions Permalink

Please sign in to leave a comment.