How To Remove Orphan Distribution Points

 Before Remove the distribution Point from the Site System, must remove the packages from the DP, But sometimes we forgot to do this often.

And then they end up with errors from each package because SCCM can´t access the server and it can´t delete the package etc (distmgr.log). It will also still list the DP under each package.

The only way is to remove the entry from the SQL Database,

Please keep in mind that manually editing the database is unsupported!

1. Backup the ConfigMgr database.

2. Find the entries for the DP package share:

Queries for finding information that needs to be delete later on.

Select * from pkgservers where NALpath like '%\\<servername>%'

Select * from pkgstatus where pkgserver like '%\\<servername>%'

Select * from contentdpmap where serverpath like '%\\<servername>%'

Select * from DPinfo where servername like '%<servername>%'

3. Delete any entries from any of the above tables that point to the nonexistent share:

Queries for deleling information about the DP that was removed earlier.

Delete from pkgservers where NALpath like '%\\<servername>%' 

Delete from pkgstatus where pkgserver like '%\\<servername>%'

Delete from contentdpmap where serverpath like '%\\<servername>%' 

Delete from DPinfo where servername like '%<servername>%'

You can also use a SDK script when the DP is alive - http://blogs.msdn.com/rslaten/archive/2006/03/01/Removing-a-retired-DP-from-all-your-packages.aspx

SCCM 2012 Client Upgrade Package Distribution Failed

Whenever you setup a new distribution point, the system will automatically distribute 2 packages to the distribution point.

          1. Configuration Manager Client Package

          2. Configuration Manager Client Upgrade Package

But somehow the Configuration Manager Client Upgrade Package failed to distribute to the distribution point. The upgrade package is hidden, hence unable to redistribute the upgrade package like normal package. Therefore, we have to trick the system to redistribute the packages.

Resolution:-

1. Open an empty notepad and save it as client.acu

2. Copy the client.acu to the inboxes\hman.box folder at the top-level site

3. Monitor the hman.log to check whether the Client Upgrade package gets updated

WDS and DHCP are running in the same SCCM Server

WDS service will not start, since DHCP and WDS both will use the same port 67 by default.

To get around this the following registry change needs to be made (UseDHCPPorts = 0)

Monitored PXEControl.log to ensure PXE was responding to tests

         
 If PXE boot still didn't work run the below command
Initialize the WDSServer (wdsutil /initialize-server /reminst:G:\RemoteInstall) 
NOTE: Adjust the G:\remoteinstall location to reality in your environment

Next you need to run the following command for the registry change made in above step
 to take affect

SCCM 2007 - Task Sequence Error 0x80004005 & NO MP Certificates

When you get the below error it might be a problem with the boot image (If you were using a boot CD for image deployment) or problem with the Management Point

It’s very advisable to investigate the smsts.log files to troubleshoot task sequence errors. The log file is located on different locations depending on the task sequence process. My reference machine rebooted even before format so I needed to get my log file from the Windows PE before HDD format: x:\windows\temp\smstslog\smsts.log. You need to press F8 during WINPE to get command line abilities and copy your log file to another destination.  Make sure that “Enable command support” is enabled in your boot image properties ( Operating system deployment – Boot images – right click your boot image – properties –  WINPE tab)

Solution - Create a new boot image & if still No MP Certificates error occurs re-install the Management Point

Supported Client Version of App-v in SCCM 2012

Before the migration of SCCM 2012 you should check the App-v client version on your environment, below are the App-v version details

App-v Client Version	Support Details
4.5.0.15341 (App-V 4.5 HF03 Jan 2009)	Not Supported in SCCM 2012
4.6.0.1523 (App-V 4.6 RTM)	Not Supported in SCCM 2012
4.6.0.20200 (App-V 4.6 All Languages)	Not Supported in SCCM 2012
4.6.1.20870 (App-V 4.6 SP1)	Not Supported in SCCM 2012
4.6.2.24020 (App-V 4.6 SP2)	Supported in SCCM 2012
4.6.2.30111 (App-V 4.6 SP2 HF03)	Supported in SCCM 2012
4.6.3.24870 (App-V 4.6 SP3)	Supported in SCCM 2012
4.6.3.25111 (APP-V 4.6 SP3 HF01)	Supported in SCCM 2012

The below SQL query will help you to find the App-v version details on your site

SELECT     dbo.v_R_System.Netbios_Name0, dbo.v_R_System.User_Name0, dbo.v_R_System.AD_Site_Name0, dbo.v_GS_OPERATING_SYSTEM.Caption0,

                      dbo.v_GS_ADD_REMOVE_PROGRAMS.DisplayName0,dbo.v_GS_ADD_REMOVE_PROGRAMS.Version0

FROM         dbo.v_R_System INNER JOIN

                      dbo.v_GS_OPERATING_SYSTEM ON dbo.v_R_System.ResourceID = dbo.v_GS_OPERATING_SYSTEM.ResourceID INNER JOIN

                      dbo.v_GS_ADD_REMOVE_PROGRAMS ON dbo.v_R_System.ResourceID = dbo.v_GS_ADD_REMOVE_PROGRAMS.ResourceID

                      where

                   

                      dbo.v_GS_ADD_REMOVE_PROGRAMS.DisplayName0 like 'Microsoft Application Virtualization Desktop Client'

If the client App-v is not upgraded, you will receive the below error on ccmsetup.log

SQL Report – Detailed Advertisement Report

SELECT dbo.v_R_System.Netbios_Name0 AS Name,

 dbo.v_ClientAdvertisementStatus.ResourceID,

 dbo.v_ClientAdvertisementStatus.LastStateName AS [Status],

 dbo.v_ClientAdvertisementStatus.LastStatusMessageIDName AS [Status Detail],

 CONVERT(datetime,

            SWITCHOFFSET(

                CONVERT(datetimeoffset,

                    dbo.v_ClientAdvertisementStatus.LastStatusTime),

  DATENAME(TzOffset, SYSDATETIMEOFFSET()))) AS StatusTime,

 dbo.v_GS_OPERATING_SYSTEM.Caption0 AS OSName,

 dbo.v_GS_OPERATING_SYSTEM.CSDVersion0 AS SP,

 dbo.v_R_System.AD_Site_Name0 AS SiteName

FROM dbo.v_ClientAdvertisementStatus LEFT OUTER JOIN

 dbo.v_GS_OPERATING_SYSTEM ON dbo.v_ClientAdvertisementStatus.ResourceID =

 dbo.v_GS_OPERATING_SYSTEM.ResourceID LEFT OUTER JOIN

 dbo.v_R_System ON dbo.v_ClientAdvertisementStatus.ResourceID = dbo.v_R_System.ResourceID

WHERE (dbo.v_ClientAdvertisementStatus.AdvertisementID = '2D020081')

ORDER BY Name

SQL Report - Package not used recently

SELECT   

      A.AdvertisementName AS [Advertisement Name],

      A.PresentTime AS Created,

      MAX(CAS.LastStatusTime) AS [Last Time Used],

      p.packageID,

      A.ProgramName,

      A.CollectionID,

      P.PkgSourcePath,

            (SELECT COUNT(PkgID) FROM vPkgStatusSummaryDistPts WHERE PkgID = p.PackageID) AS [No of DP]

FROM

      v_Package P

      INNER JOIN v_Advertisement A ON P.PackageID = A.PackageID

      INNER JOIN v_ClientAdvertisementStatus CAS ON A.AdvertisementID = CAS.AdvertisementID

WHERE

      (CAS.LastStateName != 'Accepted - No Further Status')AND

      p.PackageID NOT IN (SELECT ReferencePackageID FROM v_TaskSequenceReferencesInfo) and p.Packagetype=0

GROUP BY

      A.AdvertisementName,

      A.PresentTime,

      A.CollectionID,

      P.PkgSourcePath,

      P.Name,

      P.PackageID,

      A.ProgramName,

    P.Description

HAVING

      (MAX(CAS.LastStatusTime) IS NOT NULL)

      AND datediff(mm,MAX(CAS.LastStatusTime),getdate()-365) > 0

ORDER BY

      A.AdvertisementName,

      A.PresentTime

SUP unable to Sync with upstream Server

When you configure a Software Update Point (SUP) role on a Secondary Site/Primary Site you receive an error in the WCM.log and the SUP on secondary site is not functional.  The errors are similar to the following

From the WCM.log:

  Failed to create instance of Microsoft.SystemsManagementServer.WSUS.WSUSServer. error = Unspecified error~ 

From the WSUSctrl.log:

 Failed to create instance of Microsoft.SystemsManagementServer.WSUS.WSUSServer. error = Unspecified error~

               Failed to set WSUS Local Configuration. Will retry configuration in 1 minutes

To resolve this issue re-register the wsusmsp.dll and the wsyncact.dll files.  To do this follow these steps: 

  1.       Open a CMD window and navigate to c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\.

 2.       Run the following command lines in the order listed:

 •         RegAsm.exe C:\Program Files\Microsoft Configuration Manager\bin\i386\wsyncact.dll /unregister

•         RegAsm.exe C:\Program Files\Microsoft Configuration Manager\bin\i386\wsyncact.dll

•         c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe C:\Program Files\Microsoft Configuration Manager\bin\i386\wsusmsp.dll /unregister

•         c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe C:\Program Files\Microsoft Configuration Manager\bin\i386\wsusmsp.dll

 The above commands register the Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WSyncAction.WSyncAction  class  and the Microsoft.SystemsManagementServer.WSUS.WSUSServer class successfully.

3.       Run regedit.exe and verify that the following registry keys exist:

HKEY_CLASSES_ROOT\Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WSyncAction.WSyncAction

•         HKEY_CLASSES_ROOT\CLSID\{E5272449-2083-4020-ACEE-18A145F79A75}

4.       Wait for the next Sync status to see if the sync is working now.

Note Uninstalling and reinstalling the SUP will not resolve this issue.

Source - http://support.microsoft.com/kb/962224

MP Re-installation Command – Without Add/remove Role from Site Server

MP Re-installation Command – Without Add/remove Role from Site Server 

Site to Site Communication issue

Symptom - Site to site communication not working between  two site

Cause - .req and .job token files are accidently deleted from the SMS\Inboxes\Scheduler.box\UID folder on the SMS site server

Resolution –

·         Use a text editor to create new token .req and .job files.

·         Use a text editor to create two empty text files named ZZZZZZZZ.job and ZZZZZZZZ.req

·         Restarted the service SMS_executive

·         Once the same was done we could see site to site communication working fine and data replication will start.

Image Deployment Issue - DiskPart & SMSTS.log

Fix – we need to run the disk part command prior to the deployment

 On the Error Screen Press F8:

At the command prompt, run diskpart.

Select disk 0

Clean

Exit

Exit

At this point you can start the image deployment again

SMSTS.log

SMSTS.log helps to troubleshoot image deployment issue

The log moves around during the different stages of the OS deployment. As mentioned below it will start in:

·         x:\windows\temp\smstslog\smsts.log (When you get the error press F8 and get the log file)

·         After the format of the drive smsts.log is copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log

·         After the process is done, you can find the log file in %windir%\system32\ccm\logs\Smstslog\smsts.log

The link will guide you to get the smsts.log from the machine - http://myitforum.com/myitforumwp/2012/04/21/task-sequence-error-how-to-copy-smsts-log-from-client-4/

SCCM Client Troubleshooting

Troubleshooting Tips: Non SCCM & Unhealthy Client Machines

Sometimes the most challenging part of the Configuration Manager 2007/SMS 2003 deployment phase can be ensuring that the client successfully reports to the site server. We occasionally see these issues here in support, typically either as cases for clients not reporting after the client installation, or maybe where it’s noticed that the client count is decreasing from the collection.

When we look at the SMS/SCCM console collection, there is an entry for the client status that indicates either Yes or No. Assuming everything is installed and configured properly, a client installed on a system should automatically report as Yes, but sometimes that does not turn out to be the case. The reason could be that the client has not yet reported to the SCCM\SMS server, or it was reporting previously but has now stopped. Managing the client in the collection is a continuous task and for a healthy environment the client should be continuously reporting to the SMS\SCCM server.

There are various reasons why a client may not be able to report to even if the SMS\SCCM agent is installed on a machine. A few of these reasons are discussed below:

The first thing to check is whether the client is on the network, and if it’s not on the network, does the system even exist? It’s possible that represents a stale record from AD.

Systems NOT on the network: If the system is not actually on the network, check if it is shutdown, and if so if it’s been shut down for long time. If yes then first restart the system and then initiate the discovery cycle from the control panel agent properties action TAB.

Stale Entries: When you use AD discovery, the DDRs are created for the computers that reside in the AD container that we have requested to be queried by the discovery process. If that container has the stale records for the resources, then client records may be created for systems that don’t actually exist, thus they will never report.

There is a Maintenance task that will clear the inactive records but if the discovery process runs again and the AD container still has these entries then they will simply show up again.

Resolution: For the stale records you need to make sure that the AD container is cleared of these stale records and scavenging is done for the computers container in AD regularly. Once this is done you can either make use of the maintenance task or you can create a collection for the NON SMS CLIENTS and then do a delete special to the collection so that the entries will be removed permanently from the SMS\SCCM database. Then a discovery can be run which will bring back only the active systems in the collection.

Once the agent is available on the network and the client is installed, the client goes through the following actions as part of the reporting process:

1. Client location services identify the site code and the MP it is supposed to connect to.

2. The client connects to the Management Point and downloads the policies.

3. Once the policies are downloaded it sends the heartbeat record to the server.

4. Once the server receives this heartbeat record these are converted in to DDR and processed. This will set the client flag to 1 which will make the client status display as Yes in the console.

5. On a regular basis the agent will send the heartbeat and if no heart beat or inventory shows up for a length of time then the client flag will be marked as 0 by the client flag maintenance task, setting the client status to No.

So only if this process is completed and it continues to happen will the client remain reporting to the server. This is why I said earlier that client management is a continuous task. There can be a variety of reasons why this process might fail, and I’ve outlined a couple of them below:

The Boundaries of the Agent are not specified in the site server

If the client is not assigned in the console or the client is unable to discover the site code, make sure that the AD site or the IP subnet is added in the boundary list. The server will only allow those clients within its boundary to download the policies, so if you have not specified the boundaries the client will not be authorized and the policies will not get downloaded. For boundary issues you can use this as a reference:

In the client if you check the location services.log (log location: C:\Windows\System32\CCM\Logs), you can get the information of the site assigned to it as well as the MP it is reporting to. If it is not able to report properly, you need to make sure that the agent can communicate over the network to the site server successfully.

Unable to get the site code

If the client is not able to get the site code, you need to check first the boundaries as above, and also verify that the site information is published in the AD. You can check the last part of the sitecomp.log after you start the site component manager which will say that the components like the MP, SLP etc successfully published or updated. If you are unable to see that and you get access denied errors, make sure that the computer account has read\write permission to the system container in AD. Make sure the permission is flowing to the objects within and the objects below. If you are not publishing the information in AD then you need to make sure that the SLP is configured and working.

The client itself is not installed in the Agent

To confirm this, try checking ccmexec.log file from client machine or check ccm.log from server end.

Make a list if you find any of these issues-

1. Newly discovered client computers are not assigned to the current site

2. Advanced Client Push Installation is not enabled at the appropriate site

3. The SMS Client Configuration Manager cannot connect to the client Admin$ share or to the Remote Registry Service (IPC$)

4. The SMS Advanced Client Push Installation account is configured incorrectly or is missing or is locked out

5. The SMS Advanced Client cannot access the installation file on the SMS site server

6. The SMS Advanced Client cannot access the management point during an upgrade

7. The SMS Advanced Client displays a site assignment but does not appear as installed

8. The Client computer appears in collections with the following values:

Site Code Client Assigned Client Type

This occurs when one or more of the following conditions are true:

a) The collection information has not been updated. Collection updates usually run on a daily or weekly schedule. In this case, you must make sure that the collection information has been updated. You can manually update the collection membership, and then update the collection view.

b) The client computer shares the same SMSID with another client computer. This issue can occur when you use a disk image to install the SMS Advanced Client. Duplicate SMSIDs are also referred to as duplicate GUIDs. You must determine whether duplicate SMSIDs exist on the client computers. For more information about how to detect duplicate GUIDs and how to use Tranguid.exe to create a New SMS GUID for the affected clients.

c) The SMS Advanced Client is assigned. However, the SMS Advanced Client is not installed. You must verify that the SMS Advanced Client is installed successfully and is assigned to the site that you are viewing.

d) The Network Discovery method is enabled. When you use the Network Discovery method in Systems Management Server (SMS), it populates the IsClient fields in the database by using a Null value. If other discovery methods are enabled, the computer will appear in the collection as Assigned with no client installed even though the client is installed. To resolve this issue, disable the Network Discovery method. Also, verify that the Heartbeat Discovery method that is enabled by default has not been disabled. Then, wait for the specified Heartbeat Discovery polling interval to pass. When the clients send up new discovery data, the database is updated to reflect the correct values.

Note Only the Heartbeat Discovery method will set the client installation status to Yes. The Active Directory System discovery method does not update the IsClient field in the SMS database.

e) Heartbeat Discovery has not reported since the client was installed.

There is a name resolution issue in the Client.

Make sure that the client is able to communicate to the SMS\SCCM server using the FQDN as well as the NetBIOS name. Use Nslookup or ping to check the name resolution. If you can’t ping the server using the FQDN then you will have problems.

The client is behind a firewall

If clients are behind a firewall, it may be restricting it from contacting the SMS site server. Check if the necessary ports are opened.

MP not working as a result of which the policies are not getting downloaded

You first need to check to see whether the MP is working. For that you will need to check the mpcontol .log (Log location: \SMS\logs in SMS and \program files\Microsoft Configuration Manager\logs in SCCM). If it is showing a 200 OK status code then that means the MP is working.

If the MP is working fine and the client is unable to contact and download polices, you will have an error on download in the policyagent.log file on the agent (Log location: C:\Windows\System32\CCM\Logs). Before checking this though, check if the locationservices.log has the correct MP information. If it does have the correct MP information, make sure that the BITS service is started on the client. You can try the following URLs to verify that this is working:

http:///sms_mp/.sms_aut?mplist

and

http:///sms_mp/.sms_aut?mpcert

Client is unable to download policy

You may also have issues downloading policies if the client agent has WMI corruption. If you suspect this to be the cause of your issue, if it is a XP client then follow these steps:

1. Uninstall SCCM client agent. Use the ccmsetup.exe /uninstall

2. Troubleshoot or rebuild WMI.

When to rebuild WMI : SCCM Client is not able to install on machines.

When to repair WMI : SCCM Client is installed on machines but inventory data is not reporting to SCCM database.

3. Restart the system and install the agent.
Server unable to process DDR

Once you find that the client is able to send the heartbeat data to the server, you next need to check on the server to see if these are getting processed successfully.

Clients going to NO after it had reported

1. The first reason for this is that the heartbeat discovery is enabled and that the DDRs are not reaching the server.

2. The second is that Clear Install Flag is running.

Solution: Initiate Discovery data collection cycle manually from client and update collection after few minutes.

Migrate the SCCM 2007 reports to SCCM 2012

Migrate the SCCM 2007 reports to SCCM 2012

You can’t use the built-in migration tools to migrate reports from SCCM 2007 to SCCM 2012. This leaves you with two choices; 1) Download each RDL file one by one from SCCM 2007 and upload them to SCCM 2012 or 2) Use one of the free community tools that can download multiple folders at the time. In my last project I used this tool – ReportSync – to assist me.

1. Launch ReportSync
2. In Source server type in the name of the SCCM 2007 Report server in form of http://CM01/ReportServer. Provide credentials and click Load
3. In Destination server type in the name of the SCCM 2012 Report server in form of http://CM02/ReportServer. Provide credentials and click Load
   
4. Select the folders or individual reports you want to migrate.
5. Select the Tools menu and click Map Datasources. Select the Destination data source, click Set and OK.
   
6. Click Sync
   
7. Once the process is finished click OK and your reports are now ready in SCCM 2012.
8. Run the report and verify that it works. There is no guarantee the all SCCM 2007 reports work out of the box in SCCM 2012.
   

Source - http://blog.coretech.dk/kea/migrate-reports-from-sccm-2007-to-sccm-2012-sp1/

SCCM PXE Boot – File Not Found Error

On Server which is hosting WDS service,

1.       Stop WDS service

2.       C:\WINDOWS\TEMP\PXEBootFiles\Windows

3.       Start WDS service

If you get any following errors, or the WDS service will not start, try to reinstall WDS and PXE.

PXE-E53: No boot filename received 
PXE-T01: File not found 
PXE-E3B: TFTP Error - File not Found 
PXE-E55 Proxy DHCP Service did not reply to request on port 4011 
PXE-T04: Access Violation 
PXE-E36: Error Received from TFTP Server 
PXE-M-F Exiting PXE Rom

Reinstalling WDS And The PXE Service Point

1.       Remove the SMS PXE role. Look at the PXESetup.log file to verify that the uninstall is complete and successful.

1.       Uninstall the WDS server.

2.       Reboot the machine.

3.       Re-install the WDS server, but "do not configure it". Do nothing at all other than installing WDS.

4.       Add the SMS PXE role. Look at the PXESetup.log file to verify that the installation is complete and successful.

5.       Add the boot images to the SMS PXE DP share. Look at the distmgr.log file to verify that the replication of the boot image to the DP is complete and successful.

6.       Try booting a PXE client.

For Detailed information on  TechNet