Hi There,

If you have an App-V application published via an App-V Management Server and subsequently want to change the name of the shortcut (be it published to desktop, start menu or elsewhere)… you’ll notice that making a change in either the App-V Management Console, or directly in the OSD file has no effect. You find yourself having to re-import the application which is poor if it’s in production!

The way to do this is hidden away in the application properties. Simply navigate to the properties of the application, hit the shortcut tab and select ‘Advanced’. From here select your shortcut and choose Edit, then you will be able to change the name. Refresh the App-V client and it should be updated.

This is fairly simple but has eluded me for a while and meant i’ve been re-importing applications when i’ve wanted to change the name. This way is much faster.

Thanks,
Steve

Hi There,

Update Rollup 1 has been released for System Center 2012. This update addresses a number of issues with VMM, App Controller and OpsMgr

See HERE

Thanks
SteveH

Hi there,

A customer I am working with recently implemented a new child primary site and all seemed to be ticking along smoothly until a rather angry DBA turned up to ask why disk space was being consumed at the rate of knots on the SQL server hosting the SCCM databases…First things first, I was impressed with the speed that the DBA noticed this as the database hadn’t actually grown that ‘large’, and as SCCM admins we generally keep an eye on database/backup sizes. 1-0 to the SQL DBA

Now in my experience a fast growing SCCM database generally indicates one of two things; inbox issues or more commonly – site replication issues. Given this was the first child site to be introduced in the hierarchy therefore introducing the first ‘replication’ of content then this seemed like a good avenue to start investigating.

So first things first. Let’s check the database sizes out ourselves (not that we don’t trust the DBA!). We logged on to the SQL server and reviewed the SQL ‘data’ location where we found the SCCM parent site database had ballooned by approx 20% and the new child site database was nearly the same size as the parent site which is strange given it has approx. 90% less client data!

Now that we know that an issue exists we need to identify exactly what tables contain all this ‘extra data’. To do that we need to fire up SQL Management Studio, and log on to the instance as a user with permissions to run a few queries…

First we ran the following query on  both databases to identify large tables;

http://www.sqlteam.com/downloads/BigTables.sql (please note this query is from a third party and has not been tested and as such this is run at your own risk!)

This demonstrated that on the parent site the following tables were consuming more space than expected;

• StatusMessageinsstrs
• StatusMessages
• StatusMessageAttributes

And on the new child primary site;

• TS_TaskSequences

This was the interesting table – it was approx 90% the total size of the database and only had 45 rows! The same table on the parent site was approx 2mb and had 52 rows. You can check the size directly in SQL Management Studio if you wish.

So first things first – the status messages. Let’s review the component status view in the SCCM console. From here we got a bit more information – the SMS_DISTRIBUTION_MANAGER component was flagging thousands of notifications. Viewing this component demonstrated that there were several task sequences repeatedly processing every 5 seconds. Ah! Well first things first we have a patch that should be applied to address issues with distribution points repeatadly processing content/packages/task sequences… and this is KB978021. So let’s install that (on any and all DPs) to suppress these status messages.

Now we need a solution to get rid of some of the status messages in the database of the parent site. It is bad practice to interact with the database directly and for obvious reasons is not supported by Microsoft so therefore we need to look at another way. Another blog post came up with the following solution;

• Fire up WBEMTEST
• Namespace: root\sms\site_<code>
• Execute Method
• Path: sms_statusmessage
• Select ‘Detect By Query’
• Edit In Parameters
• Select WQLSelect
• Select ‘NOT NULL’
• Query:
  • Select * from sms_statusmessage where messageid=’number’ and component = ‘SMS_DISTRIBUTION_MANAGER’

This will remove the status messages and can take some time. If there are lots of these to do then you should consider doing this in chunks. (Again, please try this in a test environment first to ensure no adverse affects occur in your production environment) It is worth noting that status messages are cleared up automatically by one of the SCCM site maintenance tasks… by default audit/component status messages are kept for 180 days, and this is configured in the status message filter section of the site settings.

We should now see the size of the parent site database has decreased. Half way there! Whilst we have stopped the status messages being generated we haven’t fixed the underlying issue. Why were these task sequences constantly processing? For that my next avenue was to look in the DISTMGR log file on the child site. Lo and behold I was greeted with the following messages;

“Failed to insert SMS Package <Packge_ID> because SDM Type Content <Unique_ContentID> is not present in the CI_Contents table. Will try later.”

These messages were repeated constantly, and there was 3 different Package ID’s referenced.

Now whilst these messages lead me to the solution it was a bit confusing as the CI_Contents table pertains to Software Updates. Now this site has a replica WSUS and did at one stage host a SUP however this was removed previously as it was added incorrectly. Whether this caused the issue we were seeing is unknown and was not investigated further.

I took the package ID and compared it to the ‘references’ tab on the task sequences that were not replicating and all the task sequences contained these packages which turned out to be Driver Packages. To resolve the issue  I simply re-created the driver package and modified the task sequences to point to the new version. Very simple, and it worked (after restarting the SMS_DISTRIBUTION_MANAGER component)… the messages disappeared from the DISTMGR log.

So we are nearly there, however one final thing we need to do is reclaim that database space to make the DBA happy. There are a number of SQL commands that can be used, however it is important to note that editing the database is not supported unless instructed to do so by Microsoft Premier Support. Doing so can leave you in an unsupported state. The commands are listed here for reference for you to use in your test environments;

• dbcc cleantable (SMS_CEN, TS_TaskSequence)
• dbcc shrinkdatabase (SMS_CEN)

Where SMS_CEN is the name of your database…
It is worth noting that these take a long time to run, approximately 1 hour per 10gb.

Thanks,
SteveH

We can finally talk/blog about it…. System Center 2012 release just announced at MMS 2012 RTM code is on your VLS! Get downloading!

It’s just been announced at MMS2012 that the next Server edition will be Windows Server 2012. We can finally drop the ’8′

Hi There,

There are a number of underlying permissions that must be granted in order for a user to be able to successfully initiate a console session to an SCCM environment.

Firstly you need to make sure the user has the correct site permissions… for example, a user requiring Remote Control access may have the following user rights;

• Collection
  • Read, Use Remote Tools, Read Resource

• Site
  • Read

Secondly this user must reside in the relevant site servers Local Group – ‘SMS Admins’. SMS Admins is generally nested in another Local Group – ‘Distributed COM Users’, and you need to check this is the case as well.

Finally, and this was the first time I’ve had to do this for a permission related issue – (and I’ve not discovered the reason why this bit of configuration had been changed or deleted) – you need to make sure that SMS Admins OR the user group containing the Remote Control users has permissions over WMI. To do this you can perform the following;

• Navigate to Server Manager
• Expand Configuration
• Select ‘Properties’ of the WMI Control Object
• Select the Security Tab
• Expand Root
• Select the SMS Folder, and choose Security

• • SMS Admins (or the group containing your users) should have the following permissions;
    • Enable Account
    • Remote Enable

• Select the site_<SiteCode> folder under SMS, and choose Security
  • SMS Admins (or the group containing your users) should have the following permissions;
    • Execute Methods
    • Provider Write
    • Enable Account
    • Remote Enable

That should be enough for your console connectivity to return

Thanks,
SteveH

Hi there,

I came across an issue recently with a child primary site that had failed to replicate a number of resources from it’s parent site.

After working through some of these issues, and rectifying the replication I needed to perform a full child resync.

This is simple to do by running the following command;

• Preinst.exe /CHILDSYNC <SiteCode>   ~ from the parent site

However an error was returned straight away stating that;

• Cannot connect to SQL Database
• <SiteCode> is not a known site

It turned out that this was because the account that I was using to run this did not have Site Modify permissions on the Parent Site. These permissions also need to be assigned directly to the account (not via a Security Group)

Once this was done, I re-run the command and a resync occurred.

Thanks,
Steve

Hi there,

Whilst re-building my lab on Server 8 Beta I came across an issue with running Vyatta which I use as a software router/firewall.

I attached the network cards as synthetic NICs and upon boot received the following error;

Spurious ACK on isa0060/serio0. Some program migh be trying to access hardware directly.

This error hangs the machine and you have to end the task to regain control.

After attempting to turn off all the advanced features of the card, e.g. SR-IOV and VMQ I was still having no luck. As a final attempt I selected the NIC and disconnected it from a vSwitch leaving it ‘Not Connected’, and booted the machine. It worked! I then reconnected the network once the router had booted and I could configure and routing worked as usual

This is only suitable in a LAB environment and would not be a solution if you were attempting to use this in production as if for any reason the router rebooted it would hang on reload. Additionally, I have not done anything in the way of performance testing as I assume the reason for the initial error is driver related.

Thanks,
SteveH

Hi There,

When the need arises to remove a Site System from DP the first thing you need to do is remove all of the roles from the Site System. However, often when you are doing this you find that the ‘ConfigMgr Component Server’ role persists which stops you from deleting the system.

Generally just leaving this for a few hours, or a couple of days works however if you are in a rush (as we all usually are!) then a quick fix is to edit another role on another site system, e.g. edit the deletion policy on a State Migration Point role. Wait for 10-15 seconds after doing that and the component server should remove on your other site system and you should get the option to delete.

As per this thread;

http://social.technet.microsoft.com/Forums/en-US/configmgrgeneral/thread/ec99a141-bede-4922-a9e9-e6605b1a7dab/

Cheers,

Recently I had the need to do a quick and dirty fix of a couple of virtual applications that had been deployed to users in an environment that uses App-V with SCCM integration. Applications are advertised to users based upon AD Security Group membership and are configured to download and execute, rather than stream from a DP.

Without going into the reasons behind why this can happen (that’s another post) – I’ll demonstrate how to quickly resolve the error and get the user back up and running. Before proceeding make sure you have got SCCM Client Center

A error of this kind would be seen by the user when attempting to launch the broken application, e.g. ;

1. Find the package ID of the affected virtual application
2. Connect to the users SCCM cache (%windir%\system32\CCM\cache) and see if the source files for the affected application are still there (use the package ID to find the folder)
3. If the cached package is still there, load SCCM client center, navigate to Agent Actions > Cache and delete the package from here (this will ensure it is not orphaned)
4. From within Client Center > Client Actions run a Download & Apply User (or machine) policy
5. On the affected machine, restart the SMS Agent Host Service (or reboot)
6. From within Client Center > Advertisements, re-run the advertisement for the failed virtual application

You should now see the application begin to download into the SCCM cache, and once complete the package should register itself with the App-V client and once again be functional.

If this fails your App-V cache may be corrupt. To resolve this you can use SFTMIME which is a tool contained within the App-V client installation directory. The following command can be used to clear all applications from within the cache;

• sftmime.exe remove obj:app /global /complete

Please note, this command will remove all applications from the App-V client, and the user running the command must have administrative permissions.

A full reference for SFTMIME can be found here;

http://technet.microsoft.com/en-us/library/cc817090.aspx

Thanks,
SteveH