anyweb

step 1. disable the FIREWALL on the xp client for testing, you can modify the firewall properties later via a GPO. step 2. verify if the configmgr client is installed on the client by going into control panel, do you see any configmgr icons ? if the OS is 64bit the icons will be in the 32 bit control panel icons... step 3. if the client is present in step 2 above, then open the Configuration Manager icon otherwise skip to Installing the Configmgr Client step 6/ click on the actions tab, and select the machine policy retrieval and evaluation cycle and click initiate action. If you only have three or so actions listed don't worry, this means that the computer hasnt got received it's list of policies yet from the SCCM server Step 4. Click on the discovery data collection cycle and initiate the action. Step 5. wait a few minutes, if the status of your XP client in the All Systems collection (make sure to refresh the collection, press F5 after choosing Update Collection Membership) still says client=no then reinstall the client Step 6. If you need to reinstall the client, highlight the computer in the All Systems collection, right click and choose Install Client, place a checkmark in 'always install or repair' and next....

USMT saving the migration data locally instead of to your State Migration Point (SMP)? according to ZtiUserstate.log you can see the following: To resolve this and get your Migration data stored on the SMP, simply disable the Determine Local or Remote UserState step in your State Capture (Scanstate) Task Sequence, then remove the C:\MININT folder *see above* then re-run the USMT state capture task sequence

thats one problem with advertising software to USERS instead of COMPUTERS another problem is if the user uses multiples computers, that way you could have applications being installed all over the place and it would be very hard to manage, the recommended solution is to advertise your software to Computer objects within the Active Directory Security Groups but remember, when you advertise software you can make it mandatory or not, if its not mandatory the user gets the choice to install it or not (if you let them), if it's mandatory then it will get installed whether the user likes it or not cheers anyweb

This topic will be used to help document and troubleshoot State Capture errors only for instance, while doing a USMT scanstate today I got the following error: to fix, browse C:\ and verify that neither the _SMSTaskSequencer or MININT folder exist, if they do, delete them and run the State Capture task sequence again. The following two log files are very important for understanding what is happening while doing a ScanState: scanstate.log scanstateprogress.log You can locate those logs here C:\WINDOWS\system32\CCM\Logs Familiarising yourself with the contents of both files will allow you to troubleshoot Scanstate much better, plus if you are doing multiple test scanstates on the same computer, you should probably delete both files prior to running a new scanstate otherwise they will become large in size and thus take longer to process in Trace32.

odd, but i'm happy you have it working now , on with the show ! cheers anyweb

download it from here http://www.microsoft.com/downloads/details...;displaylang=en while you are at it get the Microsoft® Hyper-V™ Server 2008 R2 RC as well here http://www.microsoft.com/downloads/details...;displaylang=en

hi Murda it's not hard, here is how you do it http://www.myitforum.com/forums/SCCM_task_...m_199915/tm.htm cheers anyweb

first problem is this you need to set that in Client Agents...Computer Client Agent next, you have and theres many more errors, open the log yourself using Trace32 to see the errors in Red cheers anyweb

can you post your SMSTS.log file ? cheers anyweb

remove the PXE filter and add it again, if its windows server 2008 start the action by right clicking and choose to Run the MDT PXE filter with ADministrative priviledges

forget about the TS cal's, you need to get port forwarding to work first, did you manage to port forward TCP port 3389 from your ROUTER to your SERVER's local ip address ?

after you run the machine policy it will show up in a few minutes, hit F5 to refresh

to push the client do as follows use an account that has local admin priviledges on the client to install the client, for testing purposes in a lab a domain admin account will suffice, right click the computer in configmgr All Systems collection and choose 'Install Client' cheers anyweb

looks like this is how to do it, except you dont need a port RANGE you just need to forward the port i mentioned above http://portforward.com/english/routers/por...G2/Utorrent.htm cheers anyweb

most routers are different, so i'd need to know the model name of yours to tell you how... so what is it ?

no not the ip address of the router, do these steps 1. on the server open a web browser and goto http://www.whatismyip.com 2. on the ROUTER, you need to forward TCP port 3389 to the LOCAL ip address of the server 3. now you can attempt to RDP to the ip address obtained in #1 above from a computer outside of your lan (eg: on the wan...)

just RDP to the wan IP address of the server, have you tried that ?

got another one today, this happened after I rebooted the SCCM server (this is a test lab environment with dhcp and AD/DNS all running on the same box) my virtual and real clients were getting TFTP errors namely a quick troubleshooting session via Windows Server 2008's server manager showed no problems, all roles were functioning without problems a quick look at SCCM's system status did report that the PXE service point had problems restarted WDS server service, no change to the PXE boot problem restarted DHCP server service, no change restarted DNS server service, problem solved. f.y.i.

verify the firewall is off on the client for testing, does your client have the configmgr client installed ?

Steven Sinofsky has said that Windows 7 will enter the "release to manufacturing" stage in about three months from now, meaning August '09. This means that the actual Windows 7 release would be well in time for the holiday season. " If the feedback and telemetry on Windows 7 match our expectations then we will enter the final phases of the RTM process in about 3 months. If we are successful in that, then we tracking to our shared goal of having PCs with Windows 7 available this Holiday season."

When you run Windows 7 with the default UAC level, a technique using code injection and several components in Windows 7 that can auto-elevate can totally own your system. Microsoft gave several components in Windows 7 special privileges (like notepad.exe and calc.exe) in order to reduce the amount of UAC prompts in Windows. The end result, however, is that these components can be used to bypass UAC completely, and basically get full access to your machine. This works even on the RC. The proof-of-concept exploit works by injecting its own code into the memory of another process, a process with auto-elevation capabilities. This is done using standard and documented APIs. The first proof-of-concept just copied a file to a location, but further editions could do all sorts of nasty things - and ASLR doesn't help either. This video should give you a good idea. Whiskey tango foxtrot, indeed. As the writer of the proof-of-concept code explains, the UAC API is a good API, but code does require refactoring to provide a good user experience; to not flood users with prompts. Microsoft did not do this right in Vista, and instead of addressing this issue properly in Windows 7, they took the easy way out by creating UAC backdoors for their own code and programs (the UAC whitelist) as to reduce the number of prompts. This list isn't configurable by the user. Full story and more via > http://www.osnews.com/story/21499/Why_Wind...UAC_Is_Insecure

Expand the Software Updates node in ConfigMgr and right click on Update Repository, choose Run Synchronisation. answer Yes when prompted

Step 5. Install the WSUS server as a site system in SCCM Expand the Site Database, Site Management, Site Settings node in ConfigMgr, and then expand Site systems. Right click and choose New, Server. when the new site system server wizard appears enter your details like below paying close attention to the FQDN field Note: When the computer account for the site server has access to the site system server and the site is in mixed mode, the settings on this page are optional. When the computer account does not have access to the site system server or when the site is in native mode, the following settings should be configured: Specify a fully qualified domain name (FQDN) for this site system on the intranet: This setting must be configured for the active software update point site system when the site server is in native mode or when it is in mixed mode and uses Secure Sockets Layer (SSL). By default, this setting must be configured. Specify an Internet-based fully qualified domain name for this site system: This setting must be configured for the active software update point if it accepts Internet-based client connectivity or for the active Internet-based software update point site system. Use another account for installing this site system: This setting must be configured when the computer account for the site server does not have access to the remote site system. Allow only site server initiated data transfers from this site system: This setting must be specified when the remote site system does not have access to the inboxes on the site server. This allows a site system from a different domain or forest to store the files that need to be transferred to the site server. The site server will periodically connect to the remote site system and retrieve the files. The Internet-based software update point might require this setting to be enabled. Note: you may mistakenly enter something like wsus.windows-noob.local which would be wrong, it needs the FQDN which would be wsus.sccm2007.windows-noob.local, a simple PING test to the FQDN will resolve any confusion. Select Software Update Point as the site role and click next enter your proxy settings if you have any then click next for Active Software Update Point, select the checkbox as below click next and verify your synchronisation source leave synch schedule on 7 days leave the classifications as they are *we can change them later if needed* select your products, be careful to only select what you need or it wil take forever to download everything... select your desired language (i chose english only) review the summary and click next and then close. On the ConfigMgr server, you should now see the newly added site system.

Step 4. Make the SCCM computer account a member of local administrators on your WSUS server On the WSUS server, startup Server Manager and expand Configuration and bring up Local Users and Groups. Click on Groups and then Double click on Administrators and click on Add. For 'Select This Object Type' click on Object Types, enter your administrative credentials if asked. For object types, select computers and click ok. click on Advanced and then Find Now Select the SCCM computer object from the list and click ok, this is important as we want to grant our SCCM server access to control the WSUS server, failure to do this will result in ConfigMgr Status Error Messages in the SMS_SITE_COMPONENT_MANAGER log. click ok again twice. Note: for troubleshooting purposes here is what the log would say if you fail to do the above. once you have configured the site systems computer account to be an administrator of the WSUS server, the site_component_manager will reattempt to install the site system after 60 minutes, and when successful you will see the following message in the SMS_SITE_COMPONENT_MANAGER log.

are you using windows SIM to create the xml file or are you doing it another way ?