Jump to content


lstrm

Established Members
  • Posts

    6
  • Joined

  • Last visited

lstrm's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Well, I'm aware that the general view on deploying to the All Systems collection is that it's a bad (really bad) idea. Though I still don't believe it could have any negative consequences on our system since the TS only is Available, and we don't do any superseedence updates (And we have no applications in the TS, the applications are deployed by throug the UDI script, I guess that dosent count as them being in the TS and thus being affected by any superseedence updates?). But I'm a newbie and wont risk anything by going against everyones advice so I'll leave the All Systems collection without any deployments. I'll leave it deployed to my Deployment collection, and also add it to the Unknown Systems collection. Are there any risks involved in using the default Unknown Systems collection? Or is that something you generally do? I've seen it recommended in multiple documentations and guides...
  2. I have a UDI based task sequence for deploying Windows 7. This is deployed to a specific deployment collection. Since we do a lot of random redeployments on broken machines and recieve a few new machines every couple of days, it's a bit annoying having to either move a machine to the deployment collection, or to have to manually add the machine (entering the MAC and GUID). What I'm considering is simply deploying this task sequence as an available deployment to the All Systems Collection thorugh Media and PXE. Would this be a big mistake and am I taking any risks I'm not aware of? Since the deployment is available and the UDI sequence requires user intervention before it does anything, there should be no room for mistaken deployments, or am I missing something?
  3. Now that I've got my OSD process working, I have a question around security and best practices surrounding the use of an account for automatically joining copmuters to the domain. I've really been looking around but have been unable to find anyone providing a good explanation of the potential security issues surrounding this. Right now during my LAB-deployments, I have simply provided the credentials to the task sequence, and given this account rights (or actually a security group, who the account is a member of) to manage computer objects in the client machines OU:s, this is as far as I understand how you usually do it. But as I understand it, the password for the domain join account is stored in clear text (or in some other easily decipherable form) in the task sequence. Now my plan for OSD is to constantly have a number of task sequences available to all computers so that a technichan can just choose one fitting for the machine, either through PXE boot or Software Center and start a deployment or reinstall. But this I would assume also means that any malicious employee or attacker can easily gain access to this accounts credentials, and thus potentially weak some serious havoc in my client-computer OU:s (like deleting or changing the passwords on all objects). I just can't wrap my mind around how you handle this in a safe way, or do you simply have to take a chance and risk this for the convenience of auto doman join? I'm only on my first week of sccm experience, so please do set me straight if I've completely misunderstood the process surrounding this.
  4. Thanks for your reply and for taking the time to look at the logs. The issue is now solved. It was due to some strict AV and IPS policies in the firewall. Disabling these solved the issue with the random stalling. I'm going to blame the firewall for not making any notifications that it was messing with my traffic ;-)
  5. Well, I've got an update on my issue. After updating the boot image (for enabling the command line) the .wim download speeds have increased to around 250-300Mbit. No sure why this happened, perhaps there where some CU3 updates that had not been applied since I never rebuilt the boot image before? Sadly the stalling issue while downloading drivers and package files still persists. And it seems like those downloads are still capped at around 40Mbit, but it's hard to tell for sure since the files are so small. I enabled the command line to be able to ping the sccm-server during the OSD, and the network seems to be working flawlessly, it never drops any packets.
  6. So, I'm a real newbie when it comes to SCCM. But I've managed to install and setup a Single Primary 2012 R2 running on Server 2012 R2. It's working fine, except for OS deployment. (Mostly followed Praj Waldesais step-by-step guide). It's a simple setup, using only http. The only fix I have applied is the CU3 update. There are two issues. 1. Slow download of .wim files. By slow i mean around 40Mbit/sec. It does not matter wheter I try doing an install on a physical machine on either a 100Mbit or a 1Gb link or a VM on the same host and subnet as the server. And this 40Mbit limit seems to be per machine, running three simultaneous deployments will get the total speed up to around 120Mbit (40Mbit per machine) so there does not seem to be a network bottleneck. Now I could live with a 40Mbit cap, but I think it somehow might be associated with the next problem, which is causing some serious issues... 2. After the .wim files has been downloaded and applied, the OSD sequence starts downloading drivers and packages. During this stage of the setup it seems to randomly stall on random files, sometimes it will resume the download after a minute or so, but mostly the install errors out. Like right now i have a deployment going that stalled while downloading the file "msrdcoob_x86.exe" after a minute or two the TS fails with the error 0x80070002. I've tried doing the deployments with PXE-boot and by booting from an CD/ISO. Also tried deploying different images, both Windows 7 and 8.1. I've also tried checking the "Allow clients to connect anonymously" on the DP. I've also tried with multiple physical machines, both HP and Dell. I'd really appreciate some help with this. Edit: I've attached the smsts.log from the last failed OSD (failed at the above mentioned msrdcoob_x86.exe) smsts_mydomain.log
×
×
  • 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.