Troubleshooting SCCM

Integrating SCCM and MDT 2008[/b]
For our deployments, we always install MDT 2008 on our SCCM server and select Configure ConfigMgr Integration from the MDT area on the start menu. This gives us:

Templated task sequences we can import into SCCM
Additional TS Variables for use in our task sequences
Additional options and flexibility around computer backup, USMT etc.

For beginners, the template task sequences are a very quick way to get up and running while being guided through the process, while for more advanced users the additional functionality comes in handy when your task sequences become more complex.

[b]Setting yourself up[/b]
In order to have any chance at troubleshooting SCCM OSD issues, you need to do the following:

1

Install trace32.exe which is part of the SMS 2003 Toolkit 2
(download from Here)

2

Enable command line support within your boot images:
a.  Go to the properties of your boot image(s) (right click and choose Properties)
b.  Go to the Windows PE tab and tick the Enable command support (testing only) option.
c.  When prompted, click on Yes to update your distribution points.
d.  From within your boot image (Windows PE) environment, you can now press F8 to
open up a command window — very useful for troubleshooting

3

Be familiar with your OS setup log files (e.g. WindowsXP has setupapi.log, netsetup.log etc.)[b]Log files[/b]
The root of all Task Sequence troubleshooting is called smsts.log — and this log is always the first step to troubleshooting any TS issue — if you have an issue, look in here first!

Unfortunately, the smsts.log can be stored in one of 7 locations, depending on the stage of the build and the architecture of the OS:

WindowsPE, before HDD format:
x:\windows\temp\smstslog\smsts.log
WindowsPE, after HDD format:
x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
Full version windows, before SCCM agent installed:
c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
Full version windows, after SCCM agent installed:
c:\windows\system32\ccm\logs\Smstslog\smsts.log
Full version x64 windows, after SCCM agent installed:
c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
After Task Sequence has finished running
c:\windows\system32\ccm\logs\smsts.log
After Task Sequence has finished running(x64)
c:\windows\sysWOW64\ccm\logs\smsts.log

Information is also logged as SCCM client events, which can be viewed by running the SCCM report:
Last 1000 messages for a specific computer (Errors, warnings and information)

As a general rule, the SMSTS.log provides more detail, however the SCCM client events are easier to read, and, for simple issues, can lead you to the root cause very quickly.

[b]PXE boot issues[/b]
In order to resolve PXE boot issues, there are two main log files we are interested in:

Pxecontrol.log — which is located in the installation logs directory (eg C:\Program Files (x86)\Microsoft Configuration Manager\Logs\pxecontrol.log)
Smspxe.log — which is located in MP logs directory (eg C:\Program Files (x86)\SMS_CCM\Logs\smspxe.log)
If this is the first time you’ve setup a PXE service point, I recommend you check pxecontrol.log, there should be lines similar to the following:

address to server list 192.168.00.117  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.248 2009 Cen. Australia Standard Time><thread=772 (0x304)>
adding address to server list 127.00.00.01  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.250 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Sending availiability packet to: 192.168.0.117~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.252 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Sent 274 bytes to 192.168.000.117:4011~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.253 2009 Cen. Australia Standard Time><thread=772 (0x304)>
PXE test request succeeded.~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.355 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Successfully performed availability check against local computer.~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.357 2009 Cen. Australia Standard Time><thread=772 (0x304)>

If you see otherwise, then, WDS or the PXE service point is not correctly installed.  Without going into too much detail in this area, as a catch-all fix:

Uninstall the pxe service point
Uninstall WDS
Reboot
Install WDS, but DO NOT configure
Install the pxe service point
Re-check the pxecontrol.log

Another very common error is to see the following when trying to PXE boot:

PXE-T01: The specified file was not found
PXE-E3B:TFTP error -- File not found

The x64 boot image has not been added to the PXE service point.
“But I’m only deploying an x86  boot image and OS,” I hear you say.  It doesn’t matter.  If the machine is x64 architecture (which all today’s new machines are), the boot ROM requested will be x64. This in no way effects your ability to use an x86 boot image; this boot ROM process is completely independent.The solution is to add the x64 image to your PXE DP and update. You will then see the directory \remoteinstall\smsboot\x64 populated with files, and your good to go.

Bron: klik hier

SQL Browser lijstje met Instances of servers schonen

Als je op een SQL server meerdere instances en databases hebt dan is het lastig als er een belangrijke instance verwijderd is en dat die toch steeds in dat lijstje blijft staan. Dat kan eenvoudig opgelost worden door het bestand SQLStudio.bin uit de map “%appdata%\Local\Microsoft\Microsoft SQL Server\100\Tools\Shell” te verwijderen. Let op! Je bent wel alles kwijt, maar als je gaat browsen zie je ook echt alleen de nog aanwezige instances.

Remove all Domain policies from unjoined computer

Run CMD as Administrator and run “del C:\Windows\security\database\secedit.sdb”

After deleting the security database you have also to delete some registry settings. Be carefull!

Run in the same cmd “Regedit” and go to HKLM, Software, Microsoft, Windows, Current Version and delete the key Group Policy

after that type in gpupdate /force /boot

Your computer should now be cleared of all domain policies.

DNS and DNS queries

How DNS query works

When a DNS client needs to look up a name used in a program, it queries DNS servers to resolve the name. Each query message the client sends contains three pieces of information, specifying a question for the server to answer:

  • A specified DNS domain name, stated as a fully qualified domain name (FQDN)
  • A specified query type, which can either specify a resource record by type or a specialized type of query operation
  • A specified class for the DNS domain name.

    For Windows DNS servers, this should always be specified as the Internet (IN) class.

For example, the name specified could be the FQDN for a computer, such as “host-a.example.microsoft.com.”, and the query type specified to look for an address (A) resource record by that name. Think of a DNS query as a client asking a server a two-part question, such as “Do you have any A resource records for a computer named ‘hostname.example.microsoft.com.’?” When the client receives an answer from the server, it reads and interprets the answered A resource record, learning the IP address for the computer it asked for by name.

DNS queries resolve in a number of different ways. A client can sometimes answer a query locally using cached information obtained from a previous query. The DNS server can use its own cache of resource record information to answer a query. A DNS server can also query or contact other DNS servers on behalf of the requesting client to fully resolve the name, then send an answer back to the client. This process is known as recursion.

In addition, the client itself can attempt to contact additional DNS servers to resolve a name. When a client does so, it uses separate and additional nonrecursive queries based on referral answers from servers. This process is known as iteration.

In general, the DNS query process occurs in two parts:

  • A name query begins at a client computer and is passed to a resolver, the DNS Client service, for resolution.
  • When the query cannot be resolved locally, DNS servers can be queried as needed to resolve the name.

Both of these processes are explained in more detail in the following sections.

 

Part 1: The local resolver

The following figure shows an overview of the complete DNS query process.

How a DNS query worksAs shown in the initial steps of the query process, a DNS domain name is used in a program on the local computer. The request is then passed to the DNS Client service for resolution using locally cached information. If the queried name can be resolved, the query is answered and the process is completed.

The local resolver cache can include name information obtained from two possible sources:

  • If a Hosts file is configured locally, any host name-to-address mappings from that file are preloaded into the cache when the DNS Client service is started.
  • Resource records obtained in answered responses from previous DNS queries are added to the cache and kept for a period of time.

If the query does not match an entry in the cache, the resolution process continues with the client querying a DNS server to resolve the name.

 

Part 2: Querying a DNS server

As indicated in the previous figure, the client queries a preferred DNS server. The actual server used during the initial client/server query part of the process is selected from a global list. For more information about how this global list is compiled and updated, see Client features.

When the DNS server receives a query, it first checks to see if it can answer the query authoritatively based on resource record information contained in a locally configured zone on the server. If the queried name matches a corresponding resource record in local zone information, the server answers authoritatively, using this information to resolve the queried name.

If no zone information exists for the queried name, the server then checks to see if it can resolve the name using locally cached information from previous queries. If a match is found here, the server answers with this information. Again, if the preferred server can answer with a positive matched response from its cache to the requesting client, the query is completed.

If the queried name does not find a matched answer at its preferred server — either from its cache or zone information — the query process can continue, using recursion to fully resolve the name. This involves assistance from other DNS servers to help resolve the name. By default, the DNS Client service asks the server to use a process of recursion to fully resolve names on behalf of the client before returning an answer. In most cases, the DNS server is configured, by default, to support the recursion process as shown in the following figure.

How recursion worksIn order for the DNS server to do recursion properly, it first needs some helpful contact information about other DNS servers in the DNS domain namespace. This information is provided in the form of root hints, a list of preliminary resource records that can be used by the DNS service to locate other DNS servers that are authoritative for the root of the DNS domain namespace tree. Root servers are authoritative for the domain root and top-level domains in the DNS domain namespace tree. For more information, see Updating root hints.

By using root hints to find root servers, a DNS server is able to complete the use of recursion. In theory, this process enables any DNS server to locate the servers that are authoritative for any other DNS domain name used at any level in the namespace tree.

For example, consider the use of the recursion process to locate the name “host-b.example.microsoft.com.” when the client queries a single DNS server. The process occurs when a DNS server and client are first started and have no locally cached information available to help resolve a name query. It assumes that the name queried by the client is for a domain name of which the server has no local knowledge, based on its configured zones.

First, the preferred server parses the full name and determines that it needs the location of the server that is authoritative for the top-level domain, “com”. It then uses an iterative (that is, a nonrecursive) query to the “com” DNS server to obtain a referral to the “microsoft.com” server. Next, a referral answer comes from the “microsoft.com” server to the DNS server for “example.microsoft.com”.

Finally, the “example.microsoft.com.” server is contacted. Because this server contains the queried name as part of its configured zones, it responds authoritatively back to the original server that initiated recursion. When the original server receives the response indicating that an authoritative answer was obtained to the requested query, it forwards this answer back to the requesting client and the recursive query process is completed.

Although the recursive query process can be resource-intensive when performed as described above, it has some performance advantages for the DNS server. For example, during the recursion process, the DNS server performing the recursive lookup obtains information about the DNS domain namespace. This information is cached by the server and can be used again to help speed the answering of subsequent queries that use or match it. Over time, this cached information can grow to occupy a significant portion of server memory resources, although it is cleared whenever the DNS service is cycled on and off.

 

Alternate query responses

The previous discussion of DNS queries assumes that the process ends with a positive response returned to the client. However, queries can return other answers as well. These are the most common:

  • An authoritative answer
  • A positive answer
  • A referral answer
  • A negative answer

An authoritative answer is a positive answer returned to the client and delivered with the authority bit set in the DNS message to indicate the answer was obtained from a server with direct authority for the queried name.

A positive response can consist of the queried RR or a list of RRs (also known as an RRset) that fits the queried DNS domain name and record type specified in the query message.

A referral answer contains additional resource records not specified by name or type in the query. This type of answer is returned to the client if the recursion process is not supported. The records are meant to act as helpful reference answers that the client can use to continue the query using iteration.

A referral answer contains additional data such as resource records (RRs) that are other than the type queried. For example, if the queried host name was “www” and no A RRs for this name were found in this zone but a CNAME RR for “www” was found instead, the DNS server can include that information when responding to the client.

If the client is able to use iteration, it can make additional queries using the referral information in an attempt to fully resolve the name for itself.

A negative response from the server can indicate that one of two possible results was encountered while the server attempted to process and recursively resolve the query fully and authoritatively:

  • An authoritative server reported that the queried name does not exist in the DNS namespace.
  • An authoritative server reported that the queried name exists but no records of the specified type exist for that name.

The resolver passes the results of the query, in the form of either a positive or negative response, back to the requesting program and caches the response.

Notes

  • If the resultant answer to a query is too long to be sent and resolved in a single UDP message packet, the DNS server can initiate a failover response over TCP port 53 to answer the client fully in a TCP connected session.
  • Disabling the use of recursion on a DNS server is generally done when DNS clients are being limited to resolving names to a specific DNS server, such as one located on your intranet. Recursion might also be disabled when the DNS server is incapable of resolving external DNS names, and clients are expected to fail over to another DNS server for resolution of these names.

    You can disable the use of recursion by configuring in the Advanced properties in the DNS console on the applicable server. For more information, see Disable recursion on the DNS server.

  • If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.
  • By default, DNS servers use several default timings when performing a recursive query and contacting other DNS servers. These are:
    • A recursion retry interval of 3 seconds. This is the length of time the DNS service waits before retrying a query made during a recursive lookup.
    • A recursion time-out interval of 15 seconds. This is the length of time the DNS service waits before failing a recursive lookup that has been retried.

    Under most circumstances, these parameters do not need adjustment. However, if you are using recursive lookups over a slow-speed WAN link, you might be able to improve server performance and query completion by making slight adjustments to the settings. For more information, see Tuning advanced server parameters.

 

How iteration works

Iteration is the type of name resolution used between DNS clients and servers when the following conditions are in effect:

  • The client requests the use of recursion, but recursion is disabled on the DNS server.
  • The client does not request the use of recursion when querying the DNS server.

An iterative request from a client tells the DNS server that the client expects the best answer the DNS server can provide immediately, without contacting other DNS servers.

When iteration is used, a DNS server answers a client based on its own specific knowledge about the namespace with regard to the names data being queried. For example, if a DNS server on your intranet receives a query from a local client for “www.microsoft.com”, it might return an answer from its names cache. If the queried name is not currently stored in the names cache of the server, the server might respond by providing a referral — that is, a list of NS and A resource records for other DNS servers that are closer to the name queried by the client.

When a referral is made, the DNS client assumes responsibility to continue making iterative queries to other configured DNS servers to resolve the name. For example, in the most involved case, the DNS client might expand its search as far as the root domain servers on the Internet in an effort to locate the DNS servers that are authoritative for the “com” domain. Once it contacts the Internet root servers, it can be given further iterative responses from these DNS servers that point to actual Internet DNS servers for the “microsoft.com” domain. When the client is provided records for these DNS servers, it can send another iterative query to the external Microsoft DNS servers on the Internet, which can respond with a definitive and authoritative answer.

When iteration is used, a DNS server can further assist in a name query resolution beyond giving its own best answer back to the client. For most iterative queries, a client uses its locally configured list of DNS servers to contact other name servers throughout the DNS namespace if its primary DNS server cannot resolve the query.

 

How caching works

As DNS servers process client queries using recursion or iteration, they discover and acquire a significant store of information about the DNS namespace. This information is then cached by the server.

Caching provides a way to speed the performance of DNS resolution for subsequent queries of popular names, while substantially reducing DNS-related query traffic on the network.

As DNS servers make recursive queries on behalf of clients, they temporarily cache resource records (RRs). Cached RRs contain information obtained from DNS servers that are authoritative for DNS domain names learned while making iterative queries to search and fully answer a recursive query performed on behalf of a client. Later, when other clients place new queries that request RR information matching cached RRs, the DNS server can use the cached RR information to answer them.

When information is cached, a Time-To-Live (TTL) value applies to all cached RRs. As long as the TTL for a cached RR does not expire, a DNS server can continue to cache and use the RR again when answering queries by its clients that match these RRs. Caching TTL values used by RRs in most zone configurations are assigned the Minimum (default) TTL which is set used in the zone’s start of authority (SOA) resource record. By default, the minimum TTL is 3,600 seconds (1 hour) but can be adjusted or, if needed, individual caching TTLs can be set at each RR.

Notes

  • You can install a DNS server as a caching-only server. For more information, see Using caching-only servers.
  • By default, DNS servers use a root hints file, Cache.dns, that is stored in the systemroot\System32\Dns folder on the server computer. The contents of this file are preloaded into server memory when the service is started and contain pointer information to root servers for the DNS namespace where you are operating DNS servers. For more information about this file or how it is used, see DNS-related files.

Bron: Microsoft