Date Conflict For Many Optional Applications In Software Center changes to 4/10/1998

There was interesting issue with ConfigMgr 2012 SP1 CU3 client. Many Optional applications in Software Center changes to 4/10/1998 for ‘Available After’

This issue was posted on several forums but there is not solution yet why is this happening.

After working with Microsoft, found the root cause but no permanent solution, instead we have temporary workaround to fix this issue.

Issue:

Applications appear as Old date (1998) in Software Center for ‘Available After’ which is unclear to end users about the application availability and they tend to ignore it.

During the Deployment Microsoft office project professional 2007 application, the available after date shows as 4/10/1998.Why is this?

 And when we deployed the test project professional application, it show correct date .why?

This is not application issue nor is client issue nor Server issue then where the problem,

Basic Troubleshooting:

Ø  The first thing that comes in mind is, check the Scheduled date for the Deployment, what date it is specified? You are wrong. The scheduled date is correct but it will not display here.

Ø  2nd is to look at wmi, application information is stored in “root\ccm\clientsdk” namespace.Startdate for the specific application show wrong Date.

Ø  3rd to look is, run the policy spy and check the properties for the problem package using the application assignment ID,you will see correct date which was scheduled in application deployment but why is this showing as 1998 on client machine?

Ø  4th to look at all the logs (especially policyagent.log, DCMagent.log, ccmstatestore.log) but they don’t reveal much information.

After doing lot of troubleshooting on the client, found the issue is causing because of Task Sequence .Confused?

Root Cause:

Applications which are deployed to clients are also part of Task Sequence as referenced packages, the two deployments causing the clients to go back to old Date.

More explanation:

Assume Task sequence (TS1) which is used to deploy OS is targeted to Collection (coll1) as Optional (not mandatory).This task sequence has many actions for applications For Ex: MS project professional (app1)

So the clients which are part of Collection coll1 (considering the cm12 client is installed) will have information about App1 which used in the Task sequence (TS1).

I also created deployment for App1 and targeted to MS office project collection (coll2) with available option (not required).

So far, No confusions. One TS to coll1 and one application (App1) to coll2.

After the deployment is done, if you look at the software center, if it will show wrong date (1998), then client is not synced correctly and this is happening because of 2 deployments, one from Task Sequence and other from Application Deployment.

To confirm this tested by creating few deployments for the applications used in Task sequence and deployed to test collection (for the clients who are part of TS), i see the same behavior.

Workaround: Do not use the same application which is referenced in Task sequence for the application deployment. Recreate the application used in Task sequence and deploy to clients that will show the right information for ‘available after’.

SCCM 2012 R2 – Remove Expired Updates

Hi All,

Every time i need to remove an expired update from a baseline is always the same…select the baseline, show members, and select the updates I want to remove…edit membership…

This action takes time, imagine that you need to do it once a month (yes, patch Tuesday). But, if you have many sw update groups?!?!? Yes, you’ll spend bit of time doing it.

Based on this, we can use PowerShell script as well as a console extension that will allow you to remove all expired updates from a SW update group.

To do it, download the RemoveExpiredUpdates  zip file, extract and add the files to the following places:  https://onedrive.live.com/redir?resid=AAD3278AFCB4BCA2%21271

1.    RFL-SUP Deployment Group.xml file  to <CM12R2Console Installation Path)\XmlStorage\Extensions\Actions\2853886b-cce5-4ed4-af43-df69efb2e7d8

And

2.     <CM12R2Console Installation Path)\XmlStorage\Extensions\Actions\bb1a22d4-816f-438c-b6e7-51cbc210112f (change the CM12R2Console to the path of the console )

3.    RemoveExpiredUpdates.ps1 to C:\Scripts\CM12R2Console on the same computer where you installed the CM12 R2 Console

Note: the RFL-SUP Deployment Group.xml has the same name as the href=”http://thedesktopteam.com/blog/raphael/sccm-2012-r2-sw-update-group-to-baseline/” target=”_blank”>SW Update Group to Baseline and can easily be replaced as it contains both actions. if you have not downloaded the SW Update Group to baseline, i suggest you to do it now

Once you have done it, restart the console and you’ll see a new action group called RFL Systems and once you right click any software update group, you’ll also be able to see the action (see below screenshot)

When you click, a PowerShell screen will be shown and the baseline will be created

And no worries, if there is nothing to remove, it will not do anything

  

­

You can view what port the SSB is using by running the following query on the SCCM SQL server.

SELECT name, protocol_desc, port, state_desc FROM sys.tcp_endpoints WHERE type_desc = ‘SERVICE_BROKER’

Hope This Will Work!!

Regards,

Amarpal

SCCM 2007 Distribution Point converts, but content fails

The issue is, in general, very straight forward.  The customer had several existing System Center Configuration Manager 2007 distribution points (DPs) which they wanted to upgrade to be System Center 2012 Configuration Manager DPs as part of their migration from the old product to the new.  The DP migration job ran and converted over the DP but none of the content was successful in conversion, which was really the point of the conversion in the first place.

Before I get into the gory details let me say that I have had numerous customers convert DPs and content, so why this failure occurred I don’t know.  It might have been something in the environment, it might have been a product defect, or it might have been a solar flare at the wrong time causing an electrical disruption.  In any case, the solution was so easy once we figured it out that we never bothered to spend time trying to find root cause.

The early symptom of the problem was a 2389 status message that indicated a failure to connect to the DP.  The logs seem to indicate some kind of WMI failure, which may not really be the problem.  After a bit of other troubleshooting steps we managed to follow these fairly easy steps to resolve it:

1.    Open up SQL Server Management Studio

2.    Run the following query against your ConfigMgr database, where <ServerName> is the FQDN name of the DP you are having problems with

select * from DistributionPoints  where ServerName = ‘<ServerName>’

3.    Make note of the corresponding DPID for your problem (in this example I will call it 123)

4.    Using the DPID returned form the query create an empty DPU file with the DPID as the file name

example:  123.dpu

5.    Put the file in the \Microsoft Configuration Manager\inboxes\distmgr.box

That’s it.  You should start seeing the content converted on the DP.  One query…, one DPU file…, problem solved!

Hope This Will Help !!!

Regards

Amarpal