Rocket Man

No I mean Distribution point groups. Create a DPG with your DP\SMP added as a member. Then add a collection with your system in it to this Distribution point group...see if this resolves your random SMP issue. As mentioned I briefly tested this before when I had a hub spoke topology with PS as hub and remote DPs as the spokes so to speak. I had a SMP configured at the PS DP(hub) and tried to USMT a system that resided on a spoke location, it worked but it captured the data to the PS SMP which did take quite a while over the WAN link. I added a SMP to the remote DP server where this system resided and configured the above distribution point Group solution and it worked fine, it captured the data to the remote DP/SMP where the system resided as opposed to coming across the WAN link.

The machine in question is a member of how many collections? Is there is a common collection associated with many distribution point groups, don't use USMT but did test it briefly and if I remember I had to isolate any system I was trying to state restore into a collection that was only a member of a distribution point group that only had the DP with SMP configured, once this was done it captured the settings to the correct local SMP that the system resided at.

Your application is exiting with exit code 259 which is unknown to SCCM, thus the failure in the TS. You could simply add a continue on error on that specific task of the sequence or you can dissect the application and monitor it to see why its returning the 259 code. Check Google on the error code 259 there are some fixes for it.

You can create custom sequences to deploy packages/application, run command lines etc... So yes they can be used other than OSD. You will of course need the agent on the custom configured systems prior to deploying anything from SCCM. If you can get a script created then you can use SCCM to push it out to systems but only if they have the agent installed.

have you F8 support enabled on boot images....check to see you are getting IP from DHCP server....if you are try ping fqdn of SCCM Management point\PXE server. Virtual machine should boot and communicate without any drivers so it is possible it is another issue as mentioned.

Have seen where content failed to distribute to remote DPs due to been out of time sync, but this would ultimately fail on all content. Just make sure your DPs are on correct time to that of PS. The 2 errors previous attached by you state one in 12 hour format and the remote in 24 hour format but this could be normal in the logs.

On the 2nd part...losing connection to SCCM server there is actually settings in the client and antimalware policies that allows the AV to go out to Microsoft update for definitions if it is not connected to the Configmgr network. Proves very useful in scenarios where you deploy work group or domain joined systems that will be out in the wild and disconnected from the Configmgr infrastructure, otherwise when the user manually tries to update the AV from the console it will error out, and if they don't have local admin rights they will not be able to change this setting with the windows update settings on the system.

Just deployed this out to a new lab yesterday via a clean install of OS and java 8.0 update 31 as a package attached without issues. It installed fine and verified fine also on the machines I randomly trialled verification. On another note I have a java updater package that consists of a script that will uninstall all other pre-releases if found and then install the latest version with a restart, this is done via a TS with multiple run command lines, just tested this out this morning on 3 machines that have 3 different versions of java and again it installed fine too removing the legacy versions. Are you removing older versions 1st before you install the new version?

Good to know... didn't have this included in the deployment sequence, thanks again.

Great stuff Niall. Can I ask what does the msi file contain that the January 2015 driver folder doesn't? And if using SCCM to deploy this, does it be deployed via a standard package? Thanks

You haven't imported any new W7 drivers recently and using them now in your deployments. Had similar issues when 1st deploying bitlocker to W7 clients. Turned out to be the TPM driver that I had in my DELL driver package that was causing a similar issue to what you have.

Have looked at this now ... should have looked at this prior to posting . Very informative video all the same!. Thanks Niall

Forget the previous posts. All sorted now. For anyone else that runs into this issue whilst refreshing these devices via PXE on the dock, the simple answer is to completely shutdown the devices on the dock before using the volume-down-release method of booting. Short story.....don't restart them from within windows or from the CTRL+ALT+DEL screen and expect the PXE boot method to work.......it doesn't...completely shut them down....

hi Niall Tried adding video but am unable too, see below? Thanks

Hi Niall I used that blog to add the power shell command during preparation of deployment of these devices in my enterprise, it worked a treat, so thanks. The problem I am facing is that I can't seem to PXE boot a known Surface Pro again that has been bitlockered with Chip and PIN. The surface logo appears before the PIN needs to be entered and also after the PIN is entered so how and when do you release the volume down button to get them to boot like I did when I 1st imaged them? Think it's having a PIN is the problem.

Just wondering is anybody using a Chip and Pin bitlocker encryption config with these devices. I cant seem to get them to PXE boot again successfully ( 8 attempts) when the device has a PIN applied as the surface pro logo appears before the PIN request and also after the PIN is entered so not sure if there is another method that has to be used other that holding the volume down button when powering on and releasing when the logo appears? Thanks

All routers/modems are different....some allow you to edit DNS both public and internal for DHCP clients, have no experience with Virgin modems, but TBH if it doesnt allow you to change them just get another modem that allows you to change these settings and you can still hook it up to Virgins settings for internet access. OR You could just create an internal network using virtual switch manager in Hyper-V and add all your testing systems to it and leave out the modem, because you only need this for your GW external internet access if you use the server for DHCP instead, this way will defo tell you if it is indeed DNS that is your problem by ruling out the modem all-together. OR a long way around it would be to build your test client from CD/USB add to domain(but more than likely wont not unless you manually specify the DNS to your DC) and install the SCCM client. Assign a statically assigned address to the client machine and also add static DNS to that of your DC as mentioned. Then add your new provisioned client to a SCCM collection. Create a TS that captures the network settings and deploy out to the collection to the live machine without PXE. I think it should image fine as it will capture the static settings previously assigned that has DNS set in it, but this a long way around it. Go with getting a modem that allows you to change the settings.

A VM should boot without drivers, already getting an IP proves that you have already got it to the first stage, but again when preparing network connections and your reboot happens is A DNS issue in your case, that been the client is confused and doesn't know where the management point/SCCM server is, your IPCONFIG results shows this and pinging the FQDN with no response proves it also. Your DC server's NIC primary DNS entry should be itself and no secondary entry should be in there not unless you have a multi site environment and you can put in the IP of a remote DC in the secondary NIC DNS field. Your SCCM server DNS entry should point to your DC also and nothing else. The GW for both servers should be your router IP address. In DHCP either within router setup scenario or server DHCP setup scenario your DNS should point to your DC IP Address so that any DHCP client that receives a lease from the scope will know where to resolve for internal name resolution. On your internal DNS server setup forwarders in the properties of the DNS server to point to your ISP public DNS IP addresses or simply add googles 8.8.8.8 and 8.8.4.4, so that clients looking to resolve external outside your network knows what servers they need to go to, but recommended to use your ISPs. You should concentrate on getting your internal resolution working correctly first as clients getting external access is nothing to do with your issue. If you get it setup and DNS is resolving correctly to your internal DNS/DC I think you should not have a problem not unless your management point is in a critical state presently, you have checked the health of all site components within your SCCM console?

Did you do this after making the change? If you didn't then your DHCP clients would have not been able to resolve any external addresses! Also where is the 192.168.4.100 and 192.168.8.100 DNS coming from then in your initial setup because that is not Virigins public DNS IPs or any other service providers for that matter as these are private addresses? It is a DNS issue you have and it will need to be resolved other wise you wont contact your management point which is your SCCM server. Your log in the first snippet shows this: "unknown host get host by name" "Failed to get information for management point xxxxxxxxxx" BTW are you testing at home? I have setup home test environments before on standard DSL subscriptions and used the setup I recommeneded previous and worked fine. Personally I think what Virgin have stated is a red herring.. ... you probably cant change the public DNS entries, but that is fine if you cant, in DHCP (on the router) is there any way of adding custom DNS entries? If you can then add your DC IP address and it should be bingo!

What are these? If your mask is 255.255.255.0 then how is the DNS subnets as above different than your DHCP/Servers subnet 192.168.0.x? What is the IP address of your DC server? This is what your DNS should be. Also probably be a better solution to have DHCP server on the DC and disable DHCP on the router. Then in DHCP server option enter the DNS and router configurations to point to your DC for DNS and the router to your router so that clients receiving DHCP no where the DNS server is and the router for external GW access. If you go for this solution make sure to edit the internal DNS and set the forwarders to that of your ISP public DNS servers! And also did you try and ping the FQDN of the SCCM server to see if you get a reply? ping win08-sccm.millbrook.com

Why do you have secondary DNS pointing to your router(gateway)?? Just remove this and do DNS flush on servers and clients. Can you press F8 while booting to PXE and try and ping a member server or the FQDN of the SCCM server to see if you get a reply?

Make it required only to media and PXE in the deployment options if using SCCM2012 R2! This way the machine will have to be PXE'd @ boot up time in order to run again, which in most cases is not the first boot option on a PC not unless you have changed the boot sequence. BTW if these are new machines probably better to use unknown computer support first which will leave it easier for you. Once known you can still deploy the same TS with same options to a known collection. The PXE flag is what will save it from taking off again on this type of deployment and just to add an extra layer of security Niall has blogged about creating task sequence passwords which you can add to the TS....just in case!!.

So the subnet has also changed to that of the lab environment?

A simple check and can be a reason as to why a PS fails to connect is due to time differences between CAS/PS and remote DPs. Maybe time is wrong after the transit of the DP box to it's current location?

The power management can be controlled via power management at the collection level. If you set power management on a specific device collection then the devices within the collection are governed via ConfigMgr policies, so the user has no control over this. The same go's for remote control, you specify the remote control options in the client settings. This takes precedence over a user trying to change these options.