HotdogSCCM

Do you mean you're deploying a package that is set to only run "when user is logged off"? If so, no, if a user goes to Start->Shut Down, they're not "logged off" long enough for CCM to fire off the install; in fact, if you watch CCMEXEC.log/other logs, the shut down process in and of itself shuts down the CCM service, so there's no time left for it to install. When you have it run "Whether or not a user is logged on" or "when user is logged on", the package will fire whenever the user is actively logged on/only when the user is logged on. Trying to make a package install ONLY when a user "literally shuts down the PC" isn't possible. You'd want a legitimate log-off script, ala: https://technet.microsoft.com/en-us/library/Cc753583.aspx The only time I've ever been able to utilize "Logged Off" packages are for Desktops, or for environments where you know the computers are legitimately "logged off"; environments that either hide or "make difficult" to find the power-off option are good examples. On our desktops, for example, we have the default option be "log off", so there's a higher chance the user will log off instead of shut down.

How exactly far does it get? When you say "there is no NIC card after completion", do you mean completion of the entire sequence, or after it drops from PXE into full Windows (ie, after applying the image). If it is able to fully drop the WIM from within WinPE, you'll want to make sure you're also installing the correct drivers in your "Apply Drivers" step; make sure the WMI query is correct, drivers package is right, etc. My guess is it drops the WIM fine, but you're skipping the "Apply Driver" step, so it has no NIC to continue.

I vaguely remember seeing it mentioned on a blog somewhere, but can't place it now.

The sending server still has to create a snapshot of the files it needs to send; it'll create those files locally on the server and store them locally, not on the file share the source resides on. At that point it then sends from the local server out to the DPs; however, the files will still reside on the Primary in one way or another. Adding a larger HDD to the sending server should allow it to process. And, Jesus, that's a big WIM

There's a time zone bug, yeah. I assume it'll be fixed in CU1/hotfix. I've just been doing the same thing: Set it back in time and it works fine.

Howdy. We are in the process of standing up an IBCM, to service Internet clients. I have everything else squared away: Certs, ports, etc etc. The one request we have from Security, however, is to limit 8531 traffic from the IBCM back to the Primary server; from their perspective, they're not a fan of an always-accessible encrypted tunnel between the IBCM and the Primary server itself, especially since it won't follow the "Server must initiate connections" rule; ie, it'll access it every time WSUS syncs (currently, once a day). I have no big issue having them open and close it according to time; if they open it every day at 1PM and close it at 2PM, and I sync my Primary with Microsoft at 1:15PM, the IBCM will finish synching and the ports can be closed again; no muss, no fuss. However, it also looks like WCM.log goes out and checks every hour, for WSUS health. Which makes sense, mind you: Here you can see my Primary going out and validating the DMZ (internal) SUP is correct: Attempting connection to WSUS server: <DMZServer>.net, port: 8530, useSSL: False SMS_WSUS_CONFIGURATION_MANAGER 7/28/2015 1:02:03 AM 2136 (0x0858) Successfully connected to server: <DMZServer>.net, port: 8530, useSSL: False SMS_WSUS_CONFIGURATION_MANAGER 7/28/2015 1:02:03 AM 2136 (0x0858) Verify Upstream Server settings on the WSUS Server <DMZServer>.net SMS_WSUS_CONFIGURATION_MANAGER 7/28/2015 1:02:03 AM 2136 (0x0858) No changes - WSUS Server settings are correctly configured and Upstream Server is set to PRIMARYSERVER.netSMS_WSUS_CONFIGURATION_MANAGER 7/28/2015 1:02:03 AM 2136 (0x0858) So, if we limit 8531 traffic to, say, 1 hour a day, I'm guessing my health of WSUS will show alert, correct? Has anyone else done anything like this, per Security's/RMO's request? Obviously there's a plethora of other ports open as well, but the 8531 SSL tunnel they're cautious of, due to being unable to inspect the traffic between the endpoints. Thanks!