Search the Community

Hi, all. Came upon something I've not seen before. Trying to push the Config Manager client to a new server, it was going excruciatingly slow. Reading up on it led me to look at BITS stuff. Settings were all good - non-existant, actually. The only thing that helped was to change the job's priority from Normal to Foreground. That got the transfer done more or less instantly. So now the client's installed, but there are new BITS jobs stacking up. I can't get any Windows Update info from it to the CM server, etc. Now, this server sees a sustained 250-275mbit/s of inbound network traffic pretty much all the time, just by nature of the type of server it is. That leaves several hundred mbit of slack, though, as it's got a 1gbit connection. But BITS seems to be acting like its starved for bandwidth, and transfers are slow, even when the CM client is setting priority to high. We've got a server that fills an identical role and is running on identical hardware with the same NIC driver on the same network that sees even higher sustained inbound traffic (currently ~1.2gbit/s on a 3gbit/s team), but without any of this type of problem. Anyone know of a way to force BITS to be a bit more aggressive, so that things actually work? Or maybe I'm going about this wrong? E.g. ~22.5 hours after it was created, this WU job finally started, and 20-30 min after that, is only 7MB along. PS Z:\TOOLS\pstools> Get-BitsTransfer -allusers -name "wu*" | fl JobId : b70f15ba-cb48-4cbb-9487-fec406bcc230 DisplayName : WU Client Download TransferType : Download JobState : Transferring OwnerAccount : NT AUTHORITY\SYSTEM Priority : High TransferPolicy : NoSurcharge FilesTransferred : 0 FilesTotal : 1 BytesTransferred : 7577239 BytesTotal : 96814352 CreationTime : 1/23/2018 2:58:51 PM ModificationTime : 1/24/2018 1:50:56 PM MinimumRetryDelay : NoProgressTimeout : TransientErrorCount : 0 ProxyUsage : NoProxy ProxyList : ProxyBypassList : Others are still queued up. PS Z:\TOOLS\pstools> Get-BitsTransfer -allusers | ft displayname,creationtime,modificationtime,priority,jobstate DisplayName CreationTime ModificationTime Priority JobState ----------- ------------ ---------------- -------- -------- CCMDTS Job 1/23/2018 2:16:53 PM 1/23/2018 2:16:53 PM Low Queued CCMDTS Job 1/23/2018 2:16:53 PM 1/23/2018 2:16:53 PM Low Queued CCM Message Upload {1B2D... 1/23/2018 4:22:46 PM 1/23/2018 4:22:46 PM Normal Queued CCM Message Upload {098C... 1/23/2018 6:28:45 PM 1/23/2018 6:28:45 PM Normal Queued CCM Message Upload {F0B2... 1/23/2018 8:05:32 PM 1/23/2018 8:05:32 PM Normal Queued WU Client Download 1/23/2018 2:58:51 PM 1/24/2018 1:53:51 PM High Transferring CCMDTS Job 1/23/2018 12:55:51 PM 1/24/2018 1:44:22 PM High Queued CCMDTS Job 1/23/2018 12:31:08 PM 1/24/2018 1:49:22 PM High Queued

Hi, We have had serious issues with deploying app-v applications to our VDI machines. Most of these have been solved by updating to the recent SP2 for SCCM (R2 SP1) and App-V 5 SP3, and some other minor tweaks. However it still takes to much time for all applications to be available. Our environment consists of: SCCM 2012 R2 SP1 Horizon View 5.3 Windows 7 x64 VDI clients App-V 5.0 SP3 When a user logs on to a vdi, it takes about 1-1,5 minute after the desktop is available before SCCM starts deploying user/group assigned applications. This is about a minute too long, but usable. However, usually only 1 or 2 applications are listed in Software Center and get installed. To get the rest of the applications, the user either has to wait between 10 to 60 minutes before SCCM continues with the other applications, or the user has to trigger the application deployment action via the configmgr control panel resulting in installation of the remaining apps within minutes. I have been looking at the log files but I just cannot see why it waits so long. Using policyspy from the configmgr toolkit, I can see that all the advertisements are listed under the requested tab. So the client should know there are more apps available. What I do see, is that SCCM does not see the VDI clients as a floating nonpersistent VDI: Machine Changes Persisted = Yes. Not sure if that has any influence on deployement speed. Any ideas? Where to look, what to set? Thx, Michel PS. One of the highlights of SP2 was faster app-v application deployment, but I have no idea how to get that working...

Hey Guys / Niall - I've got the strangest issue I've ever seen with SCCM and need suggestions, please. I recently started at a company which already had pretty extensive OSD TS used for all models. They have a single production OSD task sequence for use with all systems. It has a frontend that integrates with the ticketing system as well as AD and is written with AutoIT using code from the SCCM 2012 R2 SDK. The Issue One specific model specific model (Dell E5440) at only one specific site (New York branch) runs extremely slow when running the OSD TS from WinPE to standard use pf the system after imagine. When looking into it today, I ran an extensive report on a machine with the issue and my system which is in Nashville, runs fine, and is also a E5440 imaged with the same TS. I exported the reports (16mb text files each) then compared in WinMerge. What Causes it to be Slow When I reached CPU Type, I found the following difference: My Machine: Intel Core i7-4600U, 3000 MHz (30 x 100) E5440 /w Issue: Intel Core i7-4600U, 800 MHz (8 x 100) As you can see, the multiplier is somehow at 8 instead of 30. how does this happen during OSD - especially - only at a single site which runs the exact same task sequence? I looked through the TS (which I'm still becoming famailer with) but haven't seen anything which would edit the BIOS. I also took a spare 5440 and got into the BIOS myself. There's not even an option to set the multiplier there manually if I wanted to! Other Tests Performed I already mentioned that running the same TS here in Nashville (and 2 other sites) on the same model works fine. We imaged one here in Nashville, tested that it was fine, then shipped it to New York. They then imaged it (using the same task sequence we used here) and it still had the slowness issue from WinPE to standard use afterwards. Any ideas or suggestions as to how to fix and/or what is causing this to happen? Thanks!

Hello, i've had some success deploying WIndows 7 / 8.1 with bitlocker pre-provisioning. However today i've tried to bitlocker a Dell Latitude E6540 laptop and noticed the bitlocker pre provisioning step taking very long. After the wim file and the drivers are applied the disk is only encrypted to 8 % or so. After the setup configuration manager reboot the enable bitlocker ts step fails because the encryption is not completed. I've seen this behavior on older models (eg. Optiplex 960) but i would not have expected this to happen on new hardware. Has anyone experienced something similar ? I'm using: SCCM 2012 R2 on Windows Server 2008 R2 Windows ADK 8.1 Boot Images with MDT Integration (64-Bit) Models i've successfully bitlockered so far: Dell Venue Pro 11 7130 Dell Latitude E7440 Dell Latitude E6520 At first i was suspecting missing cpu features, however it might also be larger and slower disks. On working models the disk is already encrypted when maybe 10 % of the wim file is downloaded. It looks like the encryption initially (after the pre provsion step) does not complete fast enough and when the download starts the system does not keep up downloading, applying and encrypting. If i pause the the task sequence before the first reboot the encryption completes and the task sequence completes successfully.

Hello, i created a task sequence which sets up a full client with Windows 7 and needed software. The sequence is running well on the must computer models. With one computer model HP Workstation XW6200, i have the problem, that the task sequence is running well, but the installation of the software packages needs a lot more time (10x times) as on other computer models (ex. HP ProBook 6570b). Has anyone an idea? THX in advance.