Jump to content


Rocket Man

Moderators
  • Posts

    1009
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by Rocket Man

  1. Think it is a bad idea just to copy the files over....once PXE is enabled on the DP the files should automatically populate the SMSBoot x86 and x64 directories........By not doing this then there is a problem..... There is no need to uncheck the boot.wims from running from pxe service point when trying to reinstall as I have mine checked and distributed out to DPs and whenever the PXE is enabled on the DPs it automatically populates. Remove the PXE again and make sure that the new directories are also removed from the RemoteInstall folder...if not then you definitely have a connection problem from site server to DP. If it does remove the directories restart the DP, delete the Remoteinstall folder and install WDS manually from server roles but do not configure anything....restart DP again then enable THE PXE again on the DP.......see what happens this time It is stuck on contacting server because really the DP knows that they are not there as it has not been recorded through IIS. You have manually copied them there which does not work. By the way i am assuming this a remote DP that you are having problems with??
  2. Can you not just capture....any reason as to why you are building and capturing....sounds like way too much work......build your reference machine manually and install apps + updates, create a task sequence capture media and just capture the machine....You still have a custom image at the end of the day without the headache of having to repetitively trying to B&C unsuccessfully.. On another note have you tried to individually deploy your bundled apps via program deployment or TS?? Have you configured your programs/apps to be allowed to be deployed via a Task sequence?? (it is in the properties of the actual program in the advanced tab i think)? And you are probably correct in saying that sysprep has wiped the NIC drivers...if you had to inject them into the boot.wim to get it to connect after pxe boot, then it more than likely has wiped them again after sysprep and is unable to connect to your network share as the NIC is inactive. Try creating a capture media and just capture this model using your new boot.wim that you have added your NIC drivers to and see what happens?? If this fails to capture then the NIC drivers have been wiped, this could be a work around for this particular model.
  3. No had to allow extra protocols through our network firewall.
  4. Is it possible to use SCCM for OSD and make the target machines stay on workgroup and not install the SCCM client? If so is there a script or answerfile that i can attch that will create local accounts say one for full local rights and another account set as a standard user??
  5. options 67 and 60 should only be configured if the dhcp server is on the same server as your WDS/SCCM and not in your enviornment as you say the DHCP server is on a remote server. I had similar problems but all is fine now can you post the exact steps you are doing when trying to PXE boot clients for eg: the collection you are deploying TS to the model etc...??? and also the setup steps you have undergone to set up PXE?
  6. Can you not use the script after disk partion but before apply OS??? This script does work if inserted here and considering you have deleted the computer accounts from SCCM before OS deployment.
  7. May be simple but have you enabled the remote assistance feature on your server....this error generally means that remote assistance feature is not installed on the server.....Just because it is enabled on your client settings does not mean it will automatically work...you have to enable the feature on the server and if you have remote DPs enable the feature also on these...it can be found on server manager Roles and Features This all I have ever done and it works fine....i never tried the group policy method as i have never needed to + also all my clients are Win7 so no reason as to why it cant work on Win7 clients.
  8. Configure your collections with baseline variables i:e Packages001+ package ID & Package name (Packages001:xxxxxInternetExplorer)(Packages0002:xxxxxJava) and so on... Create a custom task sequence the edit to install application or package....choose install via baseline variable and type in packages. You can then deploy this to your different collections and depending what baseline variables you have associated with your different collections will depend on what software gets installed. this works brilliant...there is a bit of configuration and testing to be done prior but once baseline variables are configured for collections then all you need to do is deploy the simple TS with the variable Packages. I have collections that require different software for example some may need x software and others may need y software and some may need both, so if it is defined in the collection baseline then any software that is associated with the collection will be installed via the Packages TS.... you can then add the TS to your OSD TS if you wish at time of operating system deployment (considering testing has been carried out and that the sequence of the software installs works + also some software needs to be downloaded first while others can run direct from DP) It's a tedious job of elimination but worth it in the long run..
  9. After doing more digging and i think i have found my problem anyway maybe it is your problem too. On the client installation properties I have it configured for automatic site wide client push...thus the reason for the ccm log to be always active...and of course there will be failures as these machines may not be on as i am supporting over 20000 machines in my enviornment.... I am not going to change this now.......... as the old saying quotes "don't fix what's not broke"
  10. I have the same problem...couldnt get my client push to install on one particular machine today and when i opened up the CCm log it was continuously trying to push the client out to several machines......most unsuccessful even though i know that the client is already previously on these machines...the ones that showed as been successful were machines that i know for definite would have been turned on at the time... Is this usual behaviour outputs for this log?? Does ccmsetup always try to install without been requested...i do know when i initially set up my enviornment which has several remote branches...the client installed itself on several remote machines even before i had the DPs set up.....Is there a setting somewhere for automatic site client push or something like that because I am unable to explain as to why the client installed itself on these machines by itself without been pushed?? I am selecting the machine in question from the collection and right clicking and install client and go through the steps...I select the 2 bottom tick boxes. Just after checking the log again and i have not tried to push out a client in about 8 hours and it is still continouously trying to install on several machines. Any ideas how to stop this? I am not sure if this is a problem or not as I have followed the steps provided in the fourms in setting up SCCM and I have not had any problems, I am still able to install software, OSD and reporting etc..at all sites(DPs), as i said i would not of noticed this log up until I could not install the client on one particular machine and then i went digging and found this......I installed the client manually on the machine and it is fine and showing as active now and pulling it's policies as expected!!
  11. Are the errors you are recieving with clients on remote DPs by any chance?? When the client is pushed there are 2 stages it phases through...the first been the one you are getting with the basic install of the client.......after this the second part of the installation should take affect in which the client looks back to the MP to finalise the install (the custom client settings)...... I had similar problems but only with remote DPs....and it all boiled down to bad comms links between PS and RDPs...... Maybe this is your problem also...but not sure of your enviornment. Eventually after some time the full client did install....but you wudnt want to be in a hurry to get software and images deployed..
  12. Follow this....it works a treat.....SCCM will only name unknown computers to the MININT-XXXXXX that you are experiencing....If you attach this script to the TS after the partitoning of the disk and before the apply image it will prompt you to enter in a name for your bare metal machine(s)...thus preventing the MININT-XXXXXX naming convention.......You can leave the script attached to the TS all the time because if SCCM knows the name of the machine (already in the DB) then it will bypass the script and hold on the origional name of the machine(s) http://t3chn1ck.word...me-in-sccm-osd/ Rocket Man
  13. Has anyone got step by step guide to properly using prestaged content. Basically I have remote DPs with not so good links and some with very good links. The remote DPs with good links I have no problem distributing large packages to, only the remote DPs with slow links fails. I have heard that prestaging will benefit the slow link remote DPs but have no idea how to do this. I know how to enable the remote DP for prestaging content but do not know how to prestage packages and get the content to distribute the prestage way to the remote DPs. Thanks Rocket Man
  14. Have this one sorted now.......Hope this helps others with remote DPs acting as PXE service points also. Do not let SCCM create the WDS services for you by enabling PXE on the DP. Do a standard install from the server roles. Restart the server. DO configure the WDS and do not let SCCM configure it for you. Get the WDS up and running and check that clients on the LAN can recieve a PXE boot from the WDS. Once happy that the machines are recieveing a pxe boot THEN add the PXE role to the DP from the SCCM server. This will then populate the already created RemoteInstall folder with the new directories. Make sure to tick the boot images options ( Deploy this boot image from the PXE service point) before distributing them to the remote DP. i have tried endlessly following Microsoft tech docs on configuring this with no progress, as it is documented to allow SCCM to configure everthing for you.....from my testing I believe this to be untrue. If you already have WDS running on your network then leave it as it is and add the pxe service point. I have now got 15 remote DPs acting as PXE service points by configuring WDS fully before ativating the PXE from SCCM server. Hope this helps others.
  15. SCCM 2012........need help.... Does anyone have any information on setting up pxe properly. My DHCP server is on a different machine. I enabled pxe service point on the distribution point and WDS was installed and started its service. The boot images have populated the SMSBoot directory within the RemoteInstall folder, both x86 and x64 with all files pxeboot.com etc.... I have tried every configuration possible that I know off but still no luck. The best progress I made was getting it to boot once. This was achieved by having the DHCP server co-inhabitant with the DP and option 60, 66, & 67 specified in DHCP which Microsoft do not recommend applying. But as I said this worked for "1" pxe deployment and then all of a sudden stopped working. I have setup SCCM on a stand alone site with all services on the same server as the primary server and it works fine. What is so different than this PXE setup via SCCM than setting up WDS and configuring it from the server roles, after all it is only a damn PXE server. Is this a bug within SCCM2012 does anyone know. I am getting access violation errors and all sorts from trying different configurations, but still no pxe boot. The WDS works fine stand alone and clients get pxe responses with no hassel, but when the pxe role is enabled via SCCM and WDS gets installed all go's wrong. Is there permission settings on the new directories it creates, SMSBoot etc??? Any advice is appreciated. Thanks.
  16. This one is now solved after alot of head scratching... :)
  17. I have successfully set up several remote DPs and I am having trouble getting one installed. There is no difference in the DPs between any of the sites. All DPs are a new build with SCCM computer account a member of the local administrator group on the DPs. I have been following the steps throughout the installation of the successful DPs by viewing the distmgr log. All the successfully installed DPs went through the same steps apart from this one in particular. It started of the same but then went no further. I have a snippet attached of the error code and I am hoping someone may have had similar experiences and resolved this issue. The strange thing is that all the other remote DPs are no different hardware wise and OS wise from this unsuccessful DP. I have tried endlessly to get this DP to install but always with the same outcome as seen below in the snippet. Any solutions is appreciated. Thanks Rocket Man
  18. Hi Yes I have created the windows 7 collection and all of these would have the standard FEP client installed. I pushed out both policies to this collection 3 days ago. I have an update on this question through some testing. I created a new collection and added 3 clients to it. I changed the above policy in my previous post to actually install SCEP, the same configuration from your guidelines and it installed SCEP and now these 3 are reporting. So I think that you must have to specify to install SCEP in the policy as the standard FEP2010 is not manageable. Basically it removes the old FEP client and installs SCEP. Have to push the new updated policy to the windows 7 collection again!! Just another query while on this subject. I noticed when i browsed into the ccmcache directory of most of the machines that have the ConfigMgr client installed that there are approximately 6 folders in the cache all with AM delta exe or AM delta patches. This is the definitions for SCEP according to some research. Will the cache continuously grow with these definition updates or is this just the initial 4 definitions downloaded and deployed automatically via the automatic deployment created? Thanks Rocket Man
  19. Have set up the forefront role on the primary SCCM server. The SCCM 2012 server has been plugged in to the already existing network. There is a good amount clients already on this network which spans multiple sites with FEP 2010 already installed as the previous OS build. I have followed the guidelines to installing this role and creating the automatic deployment rule for the first 4 definition updates. I created the policies, but instead of specifying to install SCEP as part of the policy the only alteration I made was to manage Forefront clients ( I assume this is the correct configuration as my clients already have the FEP client installed previous to building SCCM 2012)and I just want them managed. Does it take long before the clients start reporting from the main forefront node on the server. At the moment I have only some of the clients on the network successfully deployed with ConfigMgr client and have deployed the SCEP policies also. Just curious to know if this will work or will I have to specify in the policy to install the new SCEP on the clients and overwrite or uninstall the already installed FEP client on the machines? Thanks Rocket Man
  20. Have set up the reports service point and followed the guidelines and all reports have populated the console. The initial problem was that when I went to create a custom report it gave an error about reports builder 2.0 was not installed. I changed the registry key to use 3.0 reports builder and all was fine after this. The downside to creating reports in SCCM 2012 is that to create a report it actually has to use the reports builder console, completely different from SCCM 2007R3 reporting. I also noticed that when running the built in power management reports the currency is US$ and can not be changed, is there any reason for this? Does a registry key have to be altered for this also. Thanks Rocket Man
  21. Thanks Jörgen Sorted......a fault of my own...I installed the x86 CU6 update...should of been the x64.... :/
  22. I have started a new build of SCCM 2012 using SQL server 2008R2 (enterprise) SP1 CU6 as requested in the micorsoft tech documents. The thing is I am unable to install SCCM 2012. At the point of verifying the database and instance name (leave blank for default) wizard it will not let me go any further than this. It states that I must install a verified version of SQL with appropriate hotfixes which I have. At the moment I am running server 2008R2 SP1 with SQL server 2008 R2 SP1 CU6. Is this the last cumulative update for this flavour of SQL? Am I missing something because this version of SQL is definitely supported according to Microsoft. Thanks Rocket Man
  23. A CAS site then should of been your main site if there are no clients there and your secondary site a primary site (a CAS site can not manage clients but can act as an ForeFront Endpoint and SUP service points) .....but as you say that was the way it was set up initially.... The behaviour you are experiencing is probably normal as you're TS are been deployed from the PS so the packages do need to be there on the DP also.
  24. You say that you create everything on the primary site..... but why do you create an image on the secondary site?? Is it not possible just to create the images on the PS and then send it to the DP on the the remote site, this way your main central site can deploy the TS. Also set up a distribution group, so that in the initial deployment configuration you can specify that all content be streamed from your secondary DP group and if it is not available let it fallback to your PS DP.
  25. Have you specified that this program is allowed to be deployed as part of a task sequence? This is probably why it gives this error when it tries to install as part of OSD install.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.