anyweb

those errors could be related to anything and you'll need to read the logs of each to see what it's complaining about, when installing an SCCM server and then configuring it you should expect some errors in the system status particularly if you are doing a few reboots.... cheers anyweb

use sysprep.inf to change the resolution, you could even define collection variables to do it for you in a more streamlined way for details of how that is done read Ronnis post here > http://myitforum.com/cs2/blogs/rpedersen/a...eployments.aspx please note that in his guide he has this bit sysprep.inf: [GuiUnattend] TimeZone=%LAB_OSDTimeZone% [ResionalSettings] SystemLocale=%LAB_OSDSystemLocale% SystemInput=%LAB_OSDSystemInput% [Display] XResolution=%LAB_OSDXResolution% YResolution=%LAB_OSDYResolution% which should read sysprep.inf: [GuiUnattend] TimeZone=%LAB_OSDTimeZone% [RegionalSettings] SystemLocale=%LAB_OSDSystemLocale% SystemInput=%LAB_OSDSystemInput% [Display] XResolution=%LAB_OSDXResolution% YResolution=%LAB_OSDYResolution% cheers anyweb

the easier way is KMS, but for that you'd need a special license with microsoft plus its a minimum of 25 vista desktops, you are using the OEM version of vista which uses an OEM key, and that is not designed for what you are doing, you should be using different Vista media (non oem, perhaps retail) with one license key... you see your problem is license based, what OEM are you using btw ? and what Vista Media are you using here ??? cheers anyweb

hi Jovin is AD on a separate server to your SCCM server ? if so you can ignore this bit and continue. cheers 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