Jump to content


letsgoflyers81

Established Members
  • Posts

    6
  • Joined

  • Last visited

letsgoflyers81's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges

0

Reputation

  1. Until now the team has been responsible for all SCCM management except for OSD so there was no reason to limit their access. I'm not against removing their access to All Systems now, but wouldn't I need to change the limiting collection of every collection that uses it? BAU means business as usual, day to day work such as software packaging and deployment, Windows updates, reporting and monitoring, etc.
  2. As of right now my environment only manages workstations and the team I want to limit handles almost all of our BAU activities. Because of that, most collections are limited against All Systems and the team has access to everything. I'm looking into properly implementing RBAC in the near future which will require modifying most existing collections, deployments, admin users, etc. so I was hoping there would be an easier workaround for what I'm trying to do.
  3. I know I can use Security Roles and Scopes to give administrative users access to only certain collections (for example only desktops or only servers), but I need to allow access to All Systems except for a single collection. My operational team are Full Administrators since they handle most day to day activites. However I'm considering adding some clients to the environment that I don't want them to be able to manage, deploy software or updates to, etc. I thought about copying the Full Administrator role and assigning it a new scope, but since they need access to the All Systems collection, any clients in this new collection would be there as well so I think they'd have access. Is there an easy way to do this that I'm missing? Thanks!
  4. That's the thing though, the problem isn't booting to USB. The Surface will boot to USB, I'll diskpart the hard drive, and run the task sequence. I come to a step where I remove the USB drive and select reboot, and it should boot to the WinPE environment that's been copied to the hard drive. That is where the process fails, because it only boots to the BIOS. It I re-insert the USB drive it'll boot to that just fine. Besides, after updating the firmware it started behaving exactly as the others had.
  5. The USB drive is FAT32 The boot image is x64 The hard drive had already been cleaned with diskpart so the only way to shut the device down was with the power button The USB drive and boot image are configured the same as the ones I use on my deployments. It initially boots to the drive, but once the task sequence calls for a reboot, I won't boot back to the USB drive. I resolved the issue this morning, just not how I would have liked to. I had the tech manually install OEM Windows 8.1 from a USB drive and run the SP3 update MSI. From there he was able to use the same process as before, including cleaning the hard drive with diskpart and the build started with no issue. Unless I'm missing something, the only change is the updated firmware that would survive diskpart, so the older firmware was to blame.
  6. I need some help deploying a Surface Pro 3 in SCCM 2012 SP1 (no CUs installed). I know this is not supported, but I managed to cobble together a solution which so far has worked, I'm just having trouble with one specific unit. Here's the method I used to get to this point: Use MDT 2013 to build and capture Windows 8.1 WIM which includes SP3 network drivers Use SCCM 2012 SP1 to create boot image, injecting SP3 network drivers Import WIM from MDT and use SCCM 2012 SP1 to create deploy task sequence Task sequence installs Surface Pro 3 update MSI package since importing drivers to create proper driver package does not work Other usual actions are performed such as enabling BitLocker, joining to domain, installing software packages, etc. The deployment is done with boot media rather than PXE because I've had trouble getting it to work. In order to create the boot drive I had to combine files from the MDT boot drive and SCCM boot drive. The whole process is a Frankenstein combination of MDT and SCCM that is in no way supported, but surprisingly works. We're only doing this in a very limited pilot and so far all SCCM deployments have been done by me at my site. My current problem is as follows. I had a new Surface shipped directly to a tech at another site. I distributed all the content needed to the local DP there and tried to walk him through the deployment. He created the boot drive, booted to it, diskparted the Surface, and selected the task sequence. After the WinPE environment is copied down from the network he's prompted to remove the drive and reboot. At this point it should reboot back into WinPE and continue with the deployment, that's how it works for me. But for him, it reboots directly to the BIOS if the USB drive is not inserted. I verified the hard drive has been partitioned and formatted properly and that the WinPE files have been downloaded. However it won't boot to the hard drive the way it's done on all the other Surfaces I've deployed with this method. The firmware is definitely outdated because it doesn't give the same number of boot order options, but I can't determine what version it is. The system date was also set to 2012, which I had to manually update in order for the task sequence to run at all. I'm stuck here, and I can't think of what to do next other than manually install Windows just to update the firmware and see if that helps. Any help would be greatly appreciated, since I'd hate to have to boot up manually update firmware for every new Surface we deploy. Every other Surface that was deployed in SCCM was configured and updated manually first before we established this process, so this is the first true deployment from bare metal. I know the best answer will be to upgrade my SCCM environment to a supported version, but that's out of my hands and will not be happening overnight. In the mean time, I'm trying to do whatever I can to make this work. Thanks!
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.