Rocket Man

Are you distributing the image package using the central source as the data location for the file? 9 GB is quite a large file and depending on your WAN link depends on how successful it is at distributing. If it is due to the size and not to with the possible way you have specified the data source for it then you could create a pre-stage media content file from it. This functionality is to help with large packages distributing across bad WAN links. What speed are your links?

Hi There You say you have a DP configured at your PS location and this works fine. You say you robocopied the directories from the PS DP to a remote DP? Is this correct? OR is it the Sources folder you have robocopied? There should be only one sources folders central to everything and all packages with in your hirearchy points back to this as it's data source. For example if you have 1 PS with a local DP and 15 remote DPs, there should still only be one Sources folder with all the packages content, normally this is located at the PS location in a PS ----> remote DP hirearchy. Also the reason why your imaging is pulling the wim file across the link is because you have more than likely specified in the deployment to use a remote DP if content cannot be found at the local DP. If you de-tick this option it will not look for a remote DP....but the imaging will fail as your wim file is not present within the DP boundary that your client machine resides in at the remote location.

Sound.... will give this try when I'm back @ this site. Thanks for the information and help.

Hi Apexes Thanks for the response. TBH i think the f12 prompt is only for available deployments. I have other sites that are SP1 and R2 and I never have to f12 if the Task sequence is deployed as required and to media and PXE and always re-run. The symptoms i am having is strange. If I deploy the task sequence out to the unknown computer collection as available then I have to press f12, this is as expected and this still works even on affected models. To test i just deleted some of the systems and booted them as unknown clients again and all is good. I deploy my dynamic Task sequence out to known computer collections as required and only to Media and PXE and always re-run. The PXE flag will then be set on these systems so it will have to be cleared if future deployments are needed. Works a treat. As mentioned the strange behaviour is only on affected models. On the Optiplex 390 and Virtual machines there is no need to press F12 if the task sequence is deployed out to them with this criteria. The affected models look for an f12, maybe even twice sometimes. If the f12 is not pressed the machine exits the PXE stage and looks for an F1 to retry. If f12 is pressed then the task sequence continues on successfully. I think that something maybe corrupted in the remote install folder that is causing this? But on the other hand why is it only happening on specific models, so maybe nothing is corrupt. Not sure what to do really as everything else works fine bar this. Would this have to be done in both the x86 and x64 directories? Thanks

I upgraded to SP1 a while back. Basically everything was fine in relation to PXE booting pre the upgrade. Now I have an issue where by I set the Task sequence deployment as required to only media and PXE and to always re-run. This is the functionality SP1 offers in deploying task sequences and the main reason why I upgraded also so that I could leverage this capability. What is happenening is that on the majority of the models present at this site is that they still look for an f12 to PXE to pull down the winPE image. They may even look twice for an f12. On the other hand the Optiplex 390 systems are fine, once the TS is deployed out to the collection with the same criteria set I just have to boot to PXE and the winPE image downloads without any user intervention, this is the what is expected with the criteria specified. A VM has the same outcome. Anyone came across this behaviour before? I have removed boot files and added new boot files browsing to the ADK folder and selecting the new winpe images. Added Dell winPE drivers and distributed them back out. The thing is once the f12 is pressed once or twice as needed on the affected models ...it loads and continues the task sequence as normal, but I know this is not normal to have to this with the criteria specified in the Task sequence deployment. The model affected are Dell optiplex 380, Precision 390, M65 and T3400 models. The Optiplex 390 model is fine. I also upgraded the BIOS version on the 380 but still the same outcome. Thanks

If you want to capture a reference machine you do it through capture media or B&C. Right click create Task sequence Media (not Task sequence) Select Capture media and go through the process and save your capture media. On the VM you are trying to capture simply attach the capture ISO in Hyper-V or whatever Virtual platform you are using and run it. This will sysprep the VM and capture the wim file to a share. This will then be able to be deployed out as an image to any machine and will install on the C drive.

Sysprep should not strip back software like office or Adobe, maybe some updates may get stripped. Have you checked the size of the wim file you captured, it should be larger than the 2 Gb standard wim with the software and updates installed on it?

This generally means that the system is not in a boundary/DP location where the content is. Remove the deployment for all systems ( this is not good practice deploying any kind of TS to this collection) and leave the deployment for the unknown computers. Have you seperated your collections to suit your environment and added them to the related Boundary Groups?

Have you multiple DPs in the one boundary? By not starting do you mean it throws an error stating that package xxxxxxxx is not present etc etc..?

You have a bigger problem other than Remote control. Your clients are not provisioned thus the reason as to why you only see 2 actions and thus the reason why remote control and HW/SW inventories are not working. Have you looked at the above to see if there are any errors/warnings?

Looks like your agents are not communicating at all as they are not fully provisioned by looking at the 2 only available components. Is your site or system components showing any errors? in particualr the Management Point?

Have you tried connecting to the actual IP address of a system using the remote control tool instead? Maybe DNS issues you have. You say all systems have agent... from the systems itself can you manually force H/W S/W scans without error. Can you WBEMTEST to the systems from the site server to make sure that WMI is good?

Also just double check the BIOS time and date settings, perhaps these setting are off and this can also cause these symptoms.

If you have a model specific driver bundle imported and a package created just for this model you attach the driver package to the task sequence, give it a name that suits and in the options select use a WMI query and input SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Model%" %Model% will be replaced with the model the driver pack is for. to find the criteria you need to plug into this simply log into the system, run a command line and enter in wmic csproduct get name and hit enter.... the returned result is what you place inside the quotes in the above WMI query. This will result in the task sequence checking to see if this driverpack gets installed or not on a model, if the wmi query matches that of the model then it will install that specific driver package. If it does not match it just bypasses it! This is expected, as it states clearly in your original log that it failed at this point. The reason I suspect is because it cannot find the files due to not having the correct drivers installed.

Do you have a driver specific package for this model?... if not try and manually create one or see if there is one on the web for it and use WMI query on it....the auto-apply device drivers does not work all the time, if this is what I think your doing? Also de-tick continue on error on the wireless profile, adobe readerXI and see if it bypasses the tasks then. The TS will continue on as normal with this option selected even though it has failed to install the software tasks.

Unfortunately this is still an issue. Hopefully Microsoft tech support will have a logical answer for this! In the meantime I would really like to hear if anyone else has similar symptoms. Thanks again.

Hi fourm members Recently I have noticed a strange issue into the way the SCEP 2012 R2 client reacts to USBs on win8 and 8.1 OSs'. I have one site that is all 8 & 8.1 clients and the way that the SCEP client reacts to malware infected USBs is different than that of the way it reacts to a malware infected USB on a windows 7 client. Basically if a USB has infected files contained in it and is plugged into a windows 8 or 8.1 client, the SCEP client does not remove or in any way detect this at autorun time. If the same USB is plugged into a win 7 system hosting the same SCEP client version the client automatically picks up on it at autorun time, and quarantines/removes it. Is anyone else seeing the same symptoms? If so what are your thoughts on this? I would really like to get other users to test this out. You can create the EICAR.com file and place it on the USBs for testing. This is just a testing file which is completely safe to use and test with. Here is how you can achieve this. Just paste the following code into notepad and save it as eicar.com X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* Thanks

Hi Not saying that this will work, but this is a query I associate to a collection. What it basically does is pull in any new discovered systems or imaged out of the box systems within the last day. You could probably change the 1 at the end to suit any number of days i:e if this happened 3 days ago just insert 4 to make sure that you catch all new systems both discoverd and imaged out of the box within the past 4 days! select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where DateDiff(dd,SMS_R_System.CreationDate, GetDate()) <1 This will work whether or not the agent is installed!

Good that it is working .... however I must stress the point that a dedicated SQL service account would be the best option for such services like SQL and set it that it does not expire and cannot be changed, because if any other service also used the original admin account with original password they too would not have been functioning. It is good practice to do this.

Maybe when you installed the WDS service and after the restart the SQL service did not restart automatically if SCCM, SQL and WDS on same box. Check the services on the server.

If the DP role has been removed there should still be traces left on the server hosting it i:e content folders etc, as it does not clean it up fully, well that's with my experiences of removing DPs anyway. If the DP was used for PXE the REmoteInstall folder will be still there also not unless it has been deleted manually. You could check all status messages in the monitoring node and sift through these, any changes made on the hierarchy will defo be in here, it's just a matter of finding what you are looking for.

I would not recommend deploying any type of TS to the all systems collection. For one compliance will not work as all systems include systems that have no agent and are discovered by SCCM. And more importantly if it is an OSD deployment TS you do not want all systems getting this as this may include managed servers. just a side note.

That script is what I use along with another for auto-naming to serial for laptop collections. This script will have the same affect, it will bypass it if the system is already known thus keeping the same system name. So it pretty much is doing what you have right now unfortunately. There could be scripts that allow you to re-name PCs, without having to delete the system and imaging it as a new client. Remember reading one blog quite some while ago where an engineer had a similar problem, the only difference was that he was moving systems to different location and his existing naming convention was site prefix and PC name. Now I was fairly sure there was a solution to this, but it may have involved MDT integration or/and a web-service. BTW: Still wondering how SCCM allowed you to re-image the same systems over and over again and allow you to re-name them different each time via the OSDCOMPUTERNAME variable.

You can re-image the same system over and over again by having one TS deployed to the unknown Computer Collection?? Am I getting you right?

Well the symptoms you are getting now is correct. The OSD computer name variable is applied to the unknown computers so any unknown computers will recieve this prompt. Any known system will not. How are you deploying new computers.. via unknown computer support on importing the system details? You have a task sequence deployed to the unknown computers collection as available, this works for a new system and a deleted system.... but surely when you were re-imaging before this you had a task sequence deployed out to another collection that these re-imaged PCs were in.... cuz I can't see how SCCM would allow you to re-image and re-image the same system over and over again and allow you to rename it different at the same time just by using the OSDCOMPUTERNAME variable attached to the unknown computer collection