anyweb

yup, it's either one or the other, or separate them using subnets and networking. cheers anyweb

I had this problem recently and the fix was quite easy, but finding out why it was failing (to install any updates on any machine connected to the SCCM SUP) was difficult. the basic errors in the WUAHANDLER.LOG file found on the client were repeated again and again I googled the Scan failed with error = 0x80072efd. error and got some ideas that it was a lack of commuinication between the client and the sccm sup. This turned out to be correct in the end. The SUP was a WSUS server running as a site server and was multihomed, one network card served the internal network and the other served the public. The SCCM server was on the internal network and tried to access the WSUS but got an error After much troubleshooting i decided to ping the Configuration Manager wsus server from a working machine, it reported the correct IP on the internal network. I then checked a non working client and pinged Configuration Manager wsus server from it, it replied back with the IP address of the WSUS public ip. That was the Eureka moment ~! As a quick test, and configuring IIS on the WSUS server to 'Listen To all IPs' the WSUS server was responding with the correct IP address when pinged, and windows updates started flowing hopefully this may help someone in the same situation cheers anyweb

your WDS service can exist on the sccm server or elsewhere the choice is yours, you can also upgrade a RIS service to WDS, if its windows 2003 server sp1, simply upgrade to sp2 and the ris service will become wds... please review this Technet page about WDS and SCCM cheers anyweb

welcome and thanks for your kind words :-) can you attach your SMS_MP_CONTROL_MANAGER log here please so that I can take a look at it ?

if you notice the WMI query takes place in a GROUP, and the reason for that is it 'asks' the machine what it is, and if it matches what we expect it to be, then and only then does it do all the individual STEPS within that group (quickset and whatever else you add), so if it is NOT a D430 then it will not install anything within the D430 group and it will skip the group completely and go to the next step in the task sequence. I wouldn't mix operating systems types within a task sequence, that's just asking for trouble, it's probably possible but i wouldn't do it that way i hope this helps cheers anyweb

ok then, try and catch me when i'm online and we'll do a session, my email is anyweb AT hotmail DOT com

are you willing to let me do a remote desktop to the server and look at it ?

ok so are you saying that the client software is not getting installed or that it just says 'client=no' in your collections ? is the client computer in your boundary ???

did you check your firewall settings on the client ? disable them for testing purposes the client push install account MUST BE A MEMBER of the LOCAL ADMINISTRATORS group just for the client installation, after it's installed you can remove the account from local admins group if it isnt, it will never install verify both those things cheers anyweb

ok then, continue with the REST of the guide and ignore that problem for now. We'll come back to it later but i'm sure you have a configuration issue somewhere.. if you are willing I can do a remote desktop session with you but for now, for any new problems you get please open a NEW topic/thread cheers anyweb

The Windows 7 beta release is already a few months old now, and Microsoft has already made quite a number of changes to its new windows release after that, as detailed in the Engineering 7 weblog. These changes would make it to the public via the release candidate, but it has always been a bit unclear as to when it would arrive. Thanks to a slip-up, we now know the RC is coming in May. via > http://www.osnews.com/story/21204/Windows_...e_Coming_in_May

if it says 'client=no' then a Discovery Data Cycle hasnt been run yet, try running it manually by initiating the action on the client, then do a refresh in ConfigMgr cheers anyweb

delete your X86 bootimage package and recreate it, then distribute it, then update the DP's then try again, cheers anyweb

are the servers raid ? can you not do a low level format on the hard discs which should erase any/all boot records for ever and then do a new deployment on them ?

try this net use * http://127.0.0.1/ does that work ?

is iis installed on this server or another one ? what type of USER are you doing this as ? can you copy and paste the EXACT commands you are typing and the output here please cheers

ok then, is your server an all in one ? ie, is DNS, DHCP and AD all installed on it ? i need more info...

what type of hardware do you have on this box with boot problems ?

is your firewall disabled or enabled ? have you left out any steps at all ?

post your new smsts.log file and i'll look at it to see whats wrong now cheers anyweb

adding the 64bit boot image would not break the WDS service, so you'll need to find out whats wrong with that (read the event viewer..) have you tried a server reboot ?

you have to fix this then find out what package that is (CRO00001:11) and re-distribute it...

then you need to verify that you have distributed your boot images to both the normal DP and PXE DP

try and get me the winpe logs and i'll be able to help WDS in native mode is fine, SCCM in mixed mode, also fine cheers anyweb

make sure youve added BOTH the 32 bit and 64 bit boot images then, and then distribute them to DPs read this post > http://www.windows-noob.com/forums/index.p...post&p=1354 cheers anyweb