Jump to content


wee_ads

Established Members
  • Posts

    8
  • Joined

  • Last visited

  • Days Won

    1

wee_ads last won the day on July 5 2011

wee_ads had the most liked content!

About wee_ads

  • Birthday 09/26/1975

Profile Information

  • Gender
    Male
  • Location
    Christchurch, NZ

wee_ads's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. I can vouch for this article working a treat... http://myitforum.com/myitforumwp/2011/11/08/configmgr-2012-no-need-to-manually-install-wds/ Uninstall PXE Uninstall WDS reboot server Delete the \RemoteInstall folder reboot again (for good measure) Enable PXE (and as part of this process WDS will be installed and configured accordingly). All things going well - no more WDS service "starting" problems. Cheers.
  2. Hey mate, I have encountered similar problems with configuring PXE points over the years. In the instance you have mentioned above, I found the following worked: 1. After installing the WDS role, actually configure the WDS server through the WDS console. Don't configure any DHCP options, pretty much just follow the configuration wizard and select to respond to known and unknown computers. 2. I manually set my DHCP options, but these will be specific for your setup depending on whether it on the same server as WDS, or is even in the same subnet as the Config Manager infrastructure. That said though, I have always had success with options: *** 066 - "<NETBIOS name of WDS server>" *** 067 - "boot\x86\wdsnbp.com" No matter what hardware type you are running (x86 or x64), the above references should redirect to the relevant boot image (so long as there is both an x86 and x64 boot image been uploaded to the distribution point). 3. Enable the distribution point to respond to PXE requests (as per the instructions above). As mentioned above, the DHCP options are not a standard configuration item as they depend on your setup. You may need to alter these, but I have always had good success using them. Good luck!
  3. I would assume that that is what the trusted zones drop down is supposed to make work - but as shown to date the prompt for credentials pops up - even when the trused zones is populated with the sccm server. Being RC software might mean that this may be resolved in the RTM release. As mentioned previously, by adding to the Local Intranet site alleviates the problem. This setting could easily be added into a group policy which populates this zone for all domain members (or a subset of depending on how your environment is configured).
  4. Not sure whether this will be the case or not. However, Virtual Machine Manager 2012 has been verified of being able to go from RC to RTM through an 'upgrade' process. Following that lead, although I have officially seen nothing that suggests SCCM will go down that path too, it is likely I suppose that it will. Someone else may be able to confirm that....
  5. Hey mate, I encountered the same issue and after a little research this is a 'by design' result of the browser. Using IE, add the server FQDN of the Application Catalog service to the local intranet zone. Following the above guide, you would add "sccm.server2008r2.lab.local" to the local intranet zone in IE.
  6. Hey guys, Not sure if you have gotten this sussed as yet, but I can confirm that I have successfully configured the Beta 2 release connecting with my Exchange environment. Some things to note if you're not already aware... 1. You must be connecting with an Exchange 2010 Client Access Server (CAS). I am not sure whether the whole Exchange implementation is required to be at 2010 level. 2. You must provide the FQDN of the Exchange CAS. I also populated the 'Advanced' area of the connection for good measure, but am not sure whether that is required. 3. You must use an account that has credentials for connecting to the Exchange environment. I would think that the Exchange View Only Administrator role is probably sufficient as I'm thinking that SCCM only needs to be able to read information out of Exchange?? Can anyone verify that?? These are the steps I followed a couple of times, both with success. Without the SCCM client installed on the mobile device however, I think the only real functionality is being able to wipe the device. Cheers, adrian
  7. There is also now a technet library article for SCCM 2012 and certificate requirements. http://technet.microsoft.com/en-nz/library/gg682023(en-us).aspx I actually followed this over the weekend and can vouch for it being spot on the money. There is actually no difference between the certificates for SCCM 2007 and 2012. The document signing certificate is now no longer required. One additional certificate that is not in 2007 but is in 2012 is that for the Enrollment Certificate for Mobile Devices. I deployed this fine and well, but alas having a Windows 7 phone where cab files are not supported by the OS, meant that I was not able to install the SCCM client. Check it out if you are unsure of what I mean. I'm sure by the time RTM rolls around that there will be an alternative way to install the SCCM client. Cheers, adrian
  8. Hey Kevin, Good question as I have just come across the same problem - however I've found another article which speaks about this. As of SCCM 2012 Beta 2, the PXE service point is now actually a property of the Distribution Point role. It does not appear to be associated at all with Central/Primary/Secondary sites - I would suggest that that just comes down to what is deemed a best practice. The following link talks about this in more detail: PXE Service Point changes in SCCM 2012 Beta 2 Hope this helps you out!
×
×
  • 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.