The bad News first, you cannot do that from the SCCM console. In SCCM 2007, I created a new custom Folder in which I saved all my custom made reports because I don’t wan’t to mix them up with the built-in ones. In SCCM 2012, you can create a new category with following these steps:

1. Open http://servername/Reports where “servername” has to be replaced with the servername on which the Reporting Services point role has been installed (usually the SQL Server). You should see the following:

2. Browse the folder and then create a new Folder with clicking on “New Folder”. That’s it…

I faced the issue that the Installation of the Reporting Services Point worked, but no Report could be displayed in the SCCM console. After a check in the “SMS_SRS_REPORTING_POINT” component Status, it was clear that there seems to be an issue:

I finally figured out that there is an issue with the SQL Server Reporting Services. When I tried to Access http://servername/Reports (where servername is your SQL Server with the Reporting Services component installed), there was again a message that no connection could be established to the ReportServer DB. So as a test, I created a new DB for the SQL Server Reporting Services (you can do that with the Reporting Services Configuration Manager) and…guess what…the Reports then showed up in the SCCM console. So there was an issue during the Initial Setup of the SQL Server.

I faced the issue that the “Apply Operating System” failed. I wanted to install the OS with the original MS sources, so I haven’t created a new.wim file. When I was testing it, the Task Sequence failed and the following error appeared in the smsts.log file:

The error occurding because the Folder I pointed the Operating System Installer to, only contained the install.wim file. I thought that’s all that is needed, but in fact the full Content of the OS cd is needed. The error is gone after I’ve copied the full Content and re-distributed the OS Install to the DP.

There is a nice diagram from TechNet that explains which component in the unattended file runs at what time:

I run into the issue that the collation of my existing MS SQL 2012 Server wasn’t according to the pre-requisites of the SCCM 2012 SP1 Installation. So I had to Change the collation on the SQL Server to SQL_Latin1_General_CP1_CI_AS, this is the syntax:

Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=InstanceName
/SQLSYSADMINACCOUNTS=accounts [/SAPWD= StrongPassword ] [ /SQLCOLLATION=CollationName]

In my example, I executed the following:

Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER
/SQLSYSADMINACCOUNTS=Domain\Administrator
/SQLCOLLATION=SQL_Latin1_General_CP1_CI_AS

If you have a CAG with AAC in place and once tried to do a login with Internet Explorer 10, you might know that when you enter your credentials, it always returns back to the login prompt. The issue is IE10. If you enable the compatibility view in IE10, the issue is gone. A better way to fix it is so add a meta tag into the webpage that will automatically enable the compatibility mode in IE10:

Add the following line into the meta header part of the file BasePage.aspx:

<META http-equiv=”X-UA-Compatible” content=”IE=EmulateIE9″ />

The BasePage.aspx file can be found in the root of your logon point on the AAC server.

While testing the App-V 5.0 SP2 functionality, I once came across the issue that the “Microsoft App-V Clinet” service couldn’t be started:

I found out that the there’s was an issue with the content of the folder C:\ProgramData\Microsoft\AppV\Client\Catalog\Packages\. I had one package in there, but obviously there was something wrong or misconfigured. After renaming the Catalog folder, the service was able to start. So whenever you face the issue that the service won’t start, try first to rename the folder C:\ProgramData\Microsoft\AppV\ and check if it fixes the issue. If so, you can deep dive into the subfolders/files to figure out which one exactly cause the issue.

If you once need to troubleshoot the inventory reports that the SCCM clients send to the MP server, create a file named archive_reports.sms in C:\WINDOWS\system32\CCM\Inventory\Temp. This creates an own xml file for every inventory that has been sent to the MP server. It will not automcatically delete the xml files, so make sure you remove the file when you have finished troubleshooting.

I cam across a strange behaviour after I have virtualized Quicktime 7. The following message appeared when launching Quicktime:

Next step was to troubleshoot the issue with Procmon. I started it within the bubble. This is the output:

As you can see, ExportController.exe is looking for the CoreFoundation.dll file in different locations (usual behaviour). The interesting thing is the selected line. Within the virtual bubble, this path is absolutely correct. The file is stored in this location. But the result of the file activity is “PATH NOT FOUND”, means the file isn’t there. To proove you that the file is located in that folder when you install Quicktime, see next screen shot:

As you can see, the file has been successfully found, see selected line. It’s exactly the same path as before, so why was it not working before? That’s in fact a good question. I don’t have an answer on it yet. But what is clear is that the ExportController.exe tries to access the file in the right path. The problem is that the path isn’t “translated” into the physical path. It should be **App-V Cache Folder**\PackageGUID-VersionGUID\Root\VFS\ProgramfilesCommonX86\Apple\Apple Application Support\CoreFoundation.dll. Maybe it’s a bug? I don’t know, I will try to figure it out…

Hi there. Recently I explained our trainee how App-V and in general how Application Virtualization works. I showed him how App-V isolates the registry keys by opening a cmd.exe in the virtualized environment (see my previous post for how to do that) and then running regedit. There you can see the native and the virtualized registry keys. You can see the example with a virtualized 7-zip. On the left screen shot you can see that the 7-zip registry exists. On the right screen shot you don’t see the 7-Zip key. This one was done in the native registry.

So to summarize: Whenever you open the registry within the virtual environment, you can see all the virtualized registry keys. If you open the native registry (means not in the virtualized environment), you don’t see the virtualized keys. So good so far, everything the way we expected it. Now let’s move over to the file system browsing. I take again the example of a virtualized 7-zip. I have installed 7-zip as x86 version under C:\Program Files (x86)\7-zip. BTW – this was also the Primary Virtual Application Directory (PVAD) that you have to enter during the sequencing process. Microsoft recommends to set this path the the installation directory of the application. So I did set it to C:\Program Files (x86)\7-zip. So now the big baaaang, if you browse the C:\Program Files (x86)\ directory, you won’t find the 7-zip folder:

I was confused, I believed that I will be able to browse the 7-zip program folder. So what’s going on? I tried to open the directory by cd 7-zip and that worked!

Obviously Microsoft hides the folder you define as the PVAD during the sequencing process. And there is no chance, I have disabled all settings that might hide files and folders. Why is Microsoft doing that? I don’t know, I will try to find it out.