Jump to content


coolsport00

New Members
  • Posts

    7
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

coolsport00's Achievements

Rookie

Rookie (2/14)

  • One Month Later Rare
  • Week One Done Rare
  • First Post Rare
  • Conversation Starter Rare

Recent Badges

0

Reputation

  1. Sorry for the delayed response "anyweb". I looked further into the Collections and the one assigned to the TS. These new systems, after the initial image, do indeed get added to the Collection which is assigned to the TS. So, I'm now stuck again. I am now leaning towards believing the issue has something to do with the disks in these devices. The 2 disks, a HDD and PCIe, are "backwards" as far as disk numbering go. Disk 0 is the HDD and Disk 1 is the PCIe and the PCIe is where we have the OS getting installed. Of course, we configured that to occur in the TS on initial install. But, in looking further at the logs, I'm noticing references to "disk D: drive" being referenced. That is the only thing different between all my other computers and these new ones. I think I'll just give up messing with it and simply delete the devices from SCCM whenever we need to image them, or maybe I'll create bootable media for them. Again..thanks for chiming in. Cheers!
  2. After re-reviewing the log file earlier, I had the same thought regarding the Collection it uses. But, I have some confusion here. The new devices are obviously not in SCCM & thus not in a Collection initially, yet are able to image fine. But, after the image is deployed, the devices are in SCCM (SCCM client does get installed) but not in a Collection. This may be the issue. I agree with you though...I do think somehow, based off what the log is saying, a Collection..or the lack thereof for the devices...is what the issue is. The Task Sequence is assigned to a custom Collection called "OSD - All Sytems (Excluding Servers)". Keep in mind, I didn't create, design, or administer our SCCM environment until a few mos ago. I'm still learning it all. I wish my former co-worker didn't institue UI++ into the mix, adding a layer of complexity I don't think was needed. But, it is what it is. Anyway, this Collection includes some of the System Collections - All Systems, All Unknowns, and 1 Direct computer (not sure what it is; then, it excludes MACs and Servers.
  3. Hey there "anyweb"...thanks for again for the response! Respectfully, I don't believe that is the case (protection), as I can reimage any and all other devices without issue or having to delete devices before doing so. There has to be a concrete reason for this. And it isn't "duplicate device" issue obviously since these devices are new, as I've seen in some posts while researching on this. Sure, I can delete the device out so I can reimage, but I shouldn't have to, like I don't have to for all other devices. It's annoying And, let me be a bit more detailed. We use UI++ with our boot imaging. A former co-worker set this up. I'm not completely clear on how it works, tbh. From what I can tell, it's just used in the PE part of OSD since it's set up in the Customization tab of the Boot Image; then, regular SCCM Task Sequencing takes over during OSD. When performing an OSD, I can get into the UI++ PE ok. I select my options and provide credentials to image, then when I hit Ok to begin, the dekstop just reboots. It doesn't start the Task Sequencing. In looking at the log again, I see a couple statements of interest -> "Provided preferred deployment NK120015 is not found among the available deployment"; also, "There are no task sequences available to this computer. Please ensure you have at least one task sequence deployed to this computer." ...and there obviously is a TS available. Then another msg -> "Failed to run from PXE in WinPE.... Exiting with return code 0x80004005". So maybe it seems for reimaging, a TS can't be found for the devices; yet, initial imaging it can? That's weird. I attached the smsts.log file for review, if interested. Thanks again. Cheers! smsts-alienware-18oct.log
  4. Hey gang - We just got new DELL Alienware gaming devices to disperse to high schools for gaming sports. Had to tweak things in our OSD Task Sequencing to get these to image properly due to having 2 disks (1 PCIe and 1 HDD; they were 'backwards' as far as Disk 0 & Disk 1 goes. Disk 0 is the HDD and we need the OS deployed on the PCIe). Anyway, got that sorted ok. Was able to get these imaged and settings deployed fine. But, one thing happened during my OSD testing. I can get these devices imaged, but when reimaging (which, will need to happen come next school yr), to be able to reimage, I have to delete the Alienware device from Config Manager. If I don't, after getting into the Windows PE for imaging, I enter all the settings and the computer just reboots and goes back into the OS...it doesn't 'see' the Task Sequence for OSD. I spent a wk researching why this was & found nothing. I can reimage any and all other device types (from HP to Lenovo to other DELLs) just fine without having to delete them from SCCM. Just these Alienware devices require deletion. The smsts log has no error in it to even troubleshoot why. Any of you all have any ideas why this behavior occurs? Thanks in advance. Shane (@coolsport00)
  5. As I thought...thanks much "anyweb". We planned on 'biting the bullet' and was just gonna install it after the OSD cuz there are a few configs we want to do after the OSD to the devices as well. But, I at least wanted to give getting this installed as part of the OSD a good try. You wouldn't happen to have any sure-fire ways to deploy an .exe silently, do ya? I wish MS's SCCM app deployment documentation would actually state apps *need* to be deployable silently for them to work in their documentation. Would've saved me a few days time researching/testing. Eh well...at least I gained more app deployment knowledge Cheers!
  6. Hi All - My 1st post here and somewhat new to SCCM (only a few mos in). I'm attempting to install League of Legends (LoL) during OSD as an app and it hangs for like 6hrs at this step in the Task Sequence and then fails. I looked at 2 of the smsts and smsts-#### log files on the test client device and wasn't given anything definitive in the file as to why it failed. I then broke the install down a bit to test on a Win10 client via Software Center. I figured out it needs .NET 3.5 as a pre-requisite. So, I have that part working & sorted. Installing LoL works in Software Center, but the problem is it's prompting for user interaction (only 1 action needed...to click 'Install'). I can't seem to find a silent install method/switch for the .exe. So my question is this - can applications install successfully via OSD even if there's no way to do a silent install, or must the app be configured to run silently for it to install successfully via OSD? If the answer is no...apps must be able to run silently, then I guess that would explain why it hangs during OSD for so long...seems to be awaiting an 'interaction' to click "Install" during deployment. I haven't yet reached out to LoL support to see if they have a process for installing silently and/or via SCCM. Thought I'd try here first. If anyone needs more info on this .exe, what it actually does is install the 'Riot Games' (LoL vendor) client, creates a Riot Games directory, then it opens runs the Client automatically, opening the Client window and prompting you to log in with your LoL account to then download the LoL game files to the local device. It's really a mess IMO, to say the least. There's no registry keys or anything. Maybe keys get created after you log into the Client and begin LoL download...not sure. I don't have a LoL acct. I'm just trying to get this to auto-install during OSD for new gaming devices at a school district I work at. Let me know if you all need any other info. Thanks a bunch! Shane (@coolsport00)
×
×
  • Create New...