MicroSoft Technology and Servers and Tricks.: May 2012

Wednesday, May 30, 2012

Quizapp for SCCM 2012

Helpful if you are planning for SCCM 2012 Exam 70-243

Check your Knowledge

Configuration Manager 2012: Distribution Points and PXE Services

In Configuration Manager 2012, unify infrastructure and simplify administration are two of the three key pillars of the release (the third is user empowerment). In keeping with those pillars, we have updated both the distribution point and PXE service point to make it easier to use and deploy. To explain this, let’s start by going over the Configuration Manager 2012 Distribution Point.
In Configuration Manager 2007, there were three basic types of distribution points Standard, Server Share and Branch Distribution Points. Each role had benefits, but there was not always one type that met all the administrator requirements. Starting with Configuration Manager 2012 Beta 2, we have updated the distribution point role to become one standard distribution point. Let's go over some of the details of the 2012 distribution point.
Configuration Manager 2012 Distribution Point:

One Distribution Point role (merges Standard, Branch and Server Share distribution points)
Can run on client operating systems Windows Vista SP2 and later
Can run on server operating system Windows Server 2003 SP2 and later
Requires Internet Information Services (IIS) and defaults to BITS download for clients
SMB download option for clients available for most package types
PXE service point is now just an option of the distribution point
Ability to set scheduling and throttling for content distribution (no secondary site required)
Ability to prestage content and new functionality around managing prestage distribution points (more details in a later post)
Single instance storage of content on a distribution point

The Configuration Manager 2012 distribution point now has a new storage format called the Content Library. The Content Library replaces SMSPKG shares as the default folder structure to host content. The Content Library now stores all content on the distribution point in a single instance storage, this means each unique file is only stored once on the distribution point, regardless of how many times it is referenced by a package. It also stores the file once on the distribution point even if it is contained in multiple packages!
The Content Library contains three components: File Library, Data Library and Package Library. The Data library contains all the Metadata about the files stored on the distribution point. The Package library contains all the references to the files for each package stored on the distribution point. The Data library and Package library will only reside on the drive with the lowest priority. The File library is the location that stores all the actual files that are used in packages. The files in the File library are renamed and stored based on the hash of the files. So when you browse the File library, you will most likely not recognize the individual files. Since the File library will contain GB – TB of data, the File library can be spanned across multiple volumes. (we will go into more detail in a later post).
Now let’s transition over to the changes we have made with our PXE service point. Before we think we changed a lot of let’s go over a couple of things we did not change. First, PXE services in Configuration Manager 2012 still required Windows Deployment Services (WDS). WDS needs to be installed prior to enabling PXE. This is still only available on server operating systems. Secondly, the PXE provider in Configuration Manager 2012 is mostly unchanged (aside from what we mention below and some bug fixes ). So all the troubleshooting you have learned in Configuration Manager 2007 will still be helpful. Smile

In Configuration Manager 2007 our capacity planning states “Up to 10 PXE service points per site, with a maximum of 75 PXE service points per primary site database”. One of the reasons for this is due to reliance on the Site Component Manager. Learning from our customers requirements, we have redesigned portions of our PXE service point. Starting with Configuration Manager 2012 Beta 2 the PXE service point is a property of the Distribution Point role and no longer a separate site system. Since it is a property of the distribution point, it no longer monitored or installed by SiteComp. This is now done by Distribution Manager. With this change, it will allow Configuration Manager 2012 to improve the capacity beyond the numbers published for Configuration Manager 2007. At the time of the blog post final capacity numbers are not available, but we are expecting to greatly increase this number (I will update later as numbers become available).
Another change to the PXE service point is an update to the way we interact with the site database. In Configuration Manager 2007, the PXE service point directly contacts the database to access deployment information about the client PXE booting. In Configuration Manager 2012, the PXE service point will route through the management point just like a client. This is mostly an infrastructure optimization, but important to know the flow of traffic.
Above is a overview of the infrastructure changes surrounds operating system deployments. I will start deep diving into more features in functionality over the next days to weeks. Feel free to comment if you have a specific ask for more information on portions of this overview.

Some Critical Issues/Tricks/Hidden ideas on SCCM 2007/2012 and Its Solution on One Stop.

KB2509007 does not install correctly when installed at the same time as KB977203 or KB977384 --

Solution Click Here

How To Change Logging Options For SMSTS.log in System Center Configuration Manager 2007--

How to Step by Step

Launching a Windows Defender Offline Scan with Configuration Manager 2012 OSD

How to Do

Visit and reply for more ...

Thanks

Microsoft Application Compatibility Toolkit 5.6 upload error

When installing Microsoft Application Compatibility Toolkit (ACT) it's possible to start inventory and application compatibility. ACT helps identifying which applications are compatible with Windows 7 (and Vista) operating systems. ACT is actually a collection of multiple tools. More about that HERE

In ACT it's possible to create an Inventory package, which can be deployed by Group Policy. That way an ACT Data Collector Service will be installed, which will running as long as configured in the Inventory package. The ACT service will collect application compatibility data and will send the information back to the ACT database.

But what to do when no data is returned? Just have a look at Event Viewer then. In my case there where a lot of ACT-LPS and ACTUpload errors. The ACT-LPS warning can be skipped, because it's not the problem here. The real problem is the ACTUpload error. This because I'm trying to upload inventory logs from Windows 7 SP1 devices.

The ACT v5.6 log processing server does not process logs gathered from Windows 7 or Windows Server 2008 R2 machines with SP1 installed. These logs are moved to the Failed folder on the log share and the data is not entered into the database. This is due to the fact that the ACT 5.6 database does not have an entry describing Windows 7 SP1 or Windows Server 2008 R2 SP1 and therefore does not recognize the operating system of the computer that created the log.

To resolve this problem, an entry describing Windows 7 SP1 or Windows Server 2008 R2 SP1 must be added to the ACT database's Dbo.OS table. This is described on Microsoft Support: http://support.microsoft.com/kb/2533953

It's possible also to change the Windows version in the XML files, which can be found in the [Log share]\Failed folder. A quick look in my file showed this in the 5th line of the XML: <OsInfo Id=”6.1.1” ...>
I manually changed that number to 6.1.0 and the file got imported correctly. Version 6.1.0 is for Windows 7, 6.1.1 is for Windows 7 SP1, but that’s not yet in the ACT Database. When moving files again from the [Log share]\Failed to the parent folder (one step higher) they will be in processed and placed in the [Log share]\Processed folder.

Using MAP and ACT for Windows 7 installation or migration

When migrating to Windows 7 you don't know if hardware is capable for that. Microsoft released a few tools for that, so you know if it's ready for Windows 7. These tools are Microsoft Hardware Assessment and Planning Toolkit (MAP) and Application Compatibility Toolkit (ACT). In this blogpost I will explain both tools and more tips and tricks also.

Microsoft Hardware Assessment and Planning Toolkit (MAP) is a tool that will help you prepare for a Windows 7 (or Office 2010) migration. It will help you inventory your hardware and verify that it's capable for that. MAP is an agentless, automated, multi-product planning and assessment tool for quicker and easier desktop and server migrations. Since there will be no agents installed, it uses WMI for inventory.

When starting inventory it's possible that Insufficient data is displayed. This because of non-existing objects or the're turned-off. It's possible also that firewall or WMI problems is the cause here. Most of times this can be found in the reports, which can be created. It will be saved as an Xlsx and Docx file. On the ClientAssessment tab (Xlsx) there will be errors like: Connection time out & Machine not found.

In Assessment Properties you can set custom settings for hardware requirements. That way you can decide yourself which hardware is ready for Windows 7 installation or migration. It can be used for other discoveries also. MAP can be download here: MAP v6.5

The Application Compatibility Toolkit (ACT) is a tool for inventory and application compatibility. It's kind of same as MAP, but it's strenght is on the application compatibility side. Not on the inventory side (we use MAP for that). ACT helps identifying which applications are compatible with Windows 7 (and Vista) operating systems. ACT is actually a collection of multiple tools.

In ACT it's possible to create an Inventory package, which can be deployed by Group Policy. That way an ACT Data Collector Service will be installed, which will running as long as configured in the Inventory package. The ACT service will collect application compatibility data and will send the information back to the ACT database.

When application compatibility data is collected, check Send and Receive Data, and choose which data can be synced to Microsoft. In return you get compatibility information on all applications that other people have tested before. Now you have a list of all applications with Windows 7 compatibility information. ACT can be download here: ACT v5.6

With MAP and ACT usage it's possible to check for installation and migration information and application compatibility! Just use it for free.

PXE Boot files in Remote-install folder explained

When installing WDS for PXE Boot functionality a RemoteInstall folder will be created. Most of times I install this role on the SCCM/ConfigMgr server with MDT integration. It's also possible to use a different server for that, as long the ConfigMgr PXE service point is installed on that server also.I am explaining here for the PXE Boot files which are installed.

After installation, the following files and folders are available in the RemoteInstall folder:

SMSBoot
- abortpxe.com > Used when no advertisement is available
- bootmgfw.efi > (available in x64 folder only)
- bootmgr.exe > In Boot order this is file 3 needed
- pxeboot.com > In Boot order this is file 2 needed
- pxeboot.n12 > Can be used to skip the second F12 requirement (!)
- wdsnbp.com > In Boot order this is file 1 needed (!)
SMSIMAGES
- Boot.xxx00001.wim (WDS x86 boot image)
- Boot.xxx00002.wim (WDS x64 boot image)
SMSTemp
- A temporary folder for updating boot images
Stores
- This is the Drivers (Metadate) store

The following outlines the download process.

1. A client is directed (by using DHCP Options or the PXE Server response) to download Wdsnbp.com
2. Wdsnbp.com validates the DHCP/PXE response packet and proceeds to download PXEBoot.com.
Note: PXEBoot.com requires the client to press the F12 key to initiate PXE boot. One can rename one of the other PXE boot files (such as pxeboot.n12) to download Wdsnbp.com to a different file.
3. PXEBoot.com downloads Bootmgr.exe and the BCD store. The BCD store must reside in a \Boot directory in the TFTP root folder. Additionally, the BCD store must be called BCD.
4. Bootmgr.exe reads the BCD operating system entries and downloads Boot.sdi and the Windows PE image (Winpe.wim).
5. Bootmgr.exe begins booting Windows PE by calling into Winload.exe within the Windows PE image.

And some additional information also:

When using DHCP Options for PXE Boot, Option 66 and 67 are needed. Option 66 must be the IP-address of your WDS server, Option 67 must be SMSBoot\x86\wdsnbp.com (which is the first file needed during the PXE Boot process).

The default pxeboot.com triggers an F12 requirement. The first F12 requirement is needed when Network Service boot is not on top of list in the BIOS boot order. The second F12 requirement is needed because of pxeboot.com, which is only needed when using Lite Touch Installation (LTI).

The second F12 requirement can be skipped however when renaming the default pxeboot.com to pxeboot.f12 and pxeboot.n12 (which means no F12) to pxeboot.com. After that the second F12 requirement is not needed anymore, also not for Lite Touch Installation (LTI). This must be done in both the x86 and x64 folder to make it functional.

Troubleshooting PXE related issue -
Microsoft Technet

SCCM Right Click Tool -->

SCCM Right Click Tools (NEW) Version 2.0 (4/1/2010) ( COPY & Paste)

SCCM Right Click Tools

This is version 1.1 of the SCCM Right Click Tools. It will check for the installation of the SCCM admin console and if it does not find it the installation will exit.

Version 1 includes: (This tool will not work with SMS 2003)

1.   Most of the tools that were included in the original SMS Console Additions V1.4 (thanks to those guys)
2.    The ability to see the computer details and security compliance web reports for a single client inside collections
3.    A separate drill down for client logs as well as security update client logs.
4.    The ability to check the status of an advertisement with a right click from that advertisementIn order to get the client and the advertisement web reports to work you must perform the following. Version 1.2 adds

1.    Fixed the right click tools on the “collections” that didn’t open a CMD window when running. Also fixed the echo so the results now show up in a command window

Version 1.3 adds

1.    Will detect the version of the tool installed so re-installation of unnecessary files does not occur when new versions are released
2.    Now has an entry in Add Remove Programs which enables un-installation of the program

Version 1.4 (4/9/2008)

1.   No more hard coding of your site code to get scripts and reports to run correctly
2.   Detects and uninstalls any previous versions of the tool.
3.   Right click tool added to the software updates node, but it only works if there is a update list with patches deployed.
4.   Prefixed each tool with your SCCM site code for easier recognition
5.   Right click ability on each advertisement that will display three web reports
6.   Added a prompt to see the CCMsetup.log on the SCCM Client install
7.   Fixed the Client Action for User Policy Evaluation and Update
8.   Added all the client actions from the control panel including the Security Updates Scan and Security Updates Deployment Evaluation

Version 1.5 (5/21/2008)

1.   Added an extension to the client tools that will tell you what collection a user or system belongs to. Thanks to Matthew Hudson
2.   Added a web report to show all the advertisements for a certain system.

Version 1.6 (5/30/2008)

1.   CCM and CCMSetup directories now work properly.

Version 1.7 (6/17/2008)

1.   Added the Software Updates Scan Cycle to the Collection root so it runs not just on one client but a whole collection. Requested by a member from the forum community.

Version 1.8 (2/13/2009)

1.   Added Support for Windows 2008 64bit.
2.   New Tool to Re-run advertisements from a drop down list.
3.   Added the ability to run client actions from the Query results.
4.   Fixed issue with script.bat

Version 1.9 (3/24/2009)

1.   Added Reboot/Shutdown options for client machines.

Version 2.0 (4/1/2010)

1.   Repleaced some of the VB scripts with custom HTA's
2.   Added new code to make the install easier
3.   Complete rewrite of some of the tools

LINK:--

http://myitforum.com/cs2/blogs/rhouchins/0401ConfigMgrTools.zip