Hi everyone,
For some weird reason you're not able to configure the mobile access for some of the application within the UAG 2010 portal like FileAccess, Portal, etc...
The "checkbox" for the options under "Portal Link" looks like they are disabled. :)
Following the steps below you can manually configure these settings.
1. Navigate to the root installation of the UAG using Windows Explorer.
2. Find the file WizardDefaultParam.ini located at the following path \von\conf\wizarddefaut
3. Locate the section of that application that you would like to change. For example [Portal]
4. Find the attribute "SupportPda". Change the value from "1" to "3".
5. Save the settings and restart the UAG console
6. Re-Create your "Portal" Application.
Now you should see the checkbox is checked, but still greyed out :)
/Peter
Hi,
Just a HeadsUp when designing your Forefront Endpoint Protection 2010 policy collection structure.
If you build your FEP policy assignment collection structure beneath "FEP Collections" watch out if you need to reinstall/repair the FEP installation the sub collections ends up orhpaned and after a reinstallation of the FEP installation you will not be able to see the sub collection in th console any more.
You will also get an error if you try to recreate the structure because the previously created collections still exist in the SCCM database.
"The collection name is already in use. Please enter a different name."
Follow the steps in this guide to either re-create the collection structure or remove it all together:
http://blogs.technet.com/b/mniehaus/archive/2011/04/21/got-orphaned-collections-in-configmgr.aspx
Thanks to Morten Kløve Simonsen for his input in this mather.
/Peter
Hi,
Yesterday I visited a smaller customer that had decided to do the implementation of FEP 2010 them self. Nothing wrong in that, but somewhere a long the way something had gone terrible wrong with the installation.
Error
The FEP 2010 reporting (SQL reporting services) component didn't show any data. I just stated "No Data" and "Error: Subreport could not be shown".
After doing some troubleshooting I found that I couldn't access the Microsoft SQL 2008 Analysis services using the Microsoft SQL Management studio. None of the customers services accounts had access to connect to the service.
We decided to reinstall the FEP 2010 reporting component after re-installing the Microsoft SQL 2008 Analysis service. After completing the installation everything worked.
/Peter Dahl
When you try to install the Microsoft Forefront TMG 2010 Service Pack 1 you get an error saying:
Setup cannot modify or create the registry entry System\CurrentControlSet\Services\Tcpip\Parameters.
Solution:
If you downloaded the service pack from the Microsoft Download Center, do the following:
- Press the SHIFT key and right-click on the .MSP file, and then select Copy as path.
- Right-click the Command Prompt icon, and then select Run as administrator.
- Right-click the Command Prompt window and select Paste.
- Follow the instructions in the wizard.
Source: http://technet.microsoft.com/en-us/library/ff717843.aspx
Hi everyone,
Just wanted to share a common error when publishing the UAG Direct Access group policies.
Sometimes you need to delete the published GPO objects in Active Directory and re-run the procedure for publishing the GPO in Active Directory (Click the "Apply Policy.." button).
If you get the error: failed. The system cannot find the path specified.
.
Everything looked like it successed without any errors. The Site status was all green and the sms provider had no problems accessing the ConfMgr database, but sometime after the customer began to experience problems with the site not allow for PXE and Software advertisements.
Symtoms:
As part of the task of moving the databse the SMS installation will automatically kickstart the "Perform site maintenance or reset this site" which changes the installation by running a Microsoft Installer "Change Installation" task that uses the Configuration Manager install role MSI packages to reconfigure the installation. One of these is the MP.msi which installs the ConfMgr Management Point. Sometime this fails on Windows 2008 servers due BITS not being configuration correctly.
The reconfiguration actually brakes the Management Point which results in the errors below.
You get the following failure in the mpsetup.log:
mp.msi exited with return code: 1603
Backing up drive:\program files\Microsoft Confgiuration Manager\logs\mpMSI.log to Drive:\Program Files\Microsoft Configuration Manager\logs\mpMSI.log LastError
Fatal MSI Error - mp.msi could not be installed.
You get the following failure in the smsts.log (Windows PE log):
"No MP Certificate"
Fix/Solution:
/Peter
Some weeks ago I was contacted by a customer asking me why his SCVMM Self Service Portal didn't allow him to use the custome properties during deployment of a new vm. After reviewing the picture below I was immediately convinced that it had to do with the SCVMM template not being prep'ed using sysprep. But I had to be sure.......
I therefore created a new template to reproduce the customer scenario.... If you don't Sysprep your templates before adding them to your VM Library. You will not be able to use the "System Configuration" properties from the "New Virtual Machine" wizard. All the fields like "Product Key", "Admin Password" and "Computer name" will be left grayed out. All virtual machines will retain the original configuration made during the creation of the template. Therefore any new template will have the same computer name as well. 
Recommendation / Solution
I recommend that you use the step by step guide on Technet for create a new virtual machine template:
http://technet.microsoft.com/en-us/library/cc917930.aspx
This fredag I found myself in a really weird SC Configuration Manager issue at a customer. They had created some custom reports that used the "Console User Information" collected by the Asset Intelligence in Configuration Manager to find the owner/user of their machines. For some reason the information wasn't available from even half of their machines.
The error can be seen here below:
The standard asset intelligence report (Hardware 6A - Computers for Which Console Users Could not be Determined) also returned a large amount of the Windows machine that the console user could not be determind. I verified all the prerequisites from the Microsoft Technet article (http://technet.microsoft.com/en-us/library/cc161947.aspx), but everything seemed to be in order. It was pretty weird?
After verifying all aspect of the communication between the SCCM client and server. I saw that the clients all ran the WMI query to collect the information so the SCCM client must be collecting the information.
All clients had the string "Successfully Completed Inventory for SMS_SystemConsoleUser" but only half of them worked.
I finally decided to perform the WMI query on a couple of the clients and truenought there was not value returned. Knowing that the WMI query read the security eventlog for the last 90 days of information to determind the console user I took a look at the log. I couldn't find a single logon/log off entry within the log. The log was full of log entries from the Windows Filtering Platform and due to the amount of logging that was done by the filtering platform only about an hour of data existed in the 16 megabyte large security eventlog. It's a scary thought that the filtering platform undermines the purpose of the security log.
The specific policies “Audit Filtering Platform Connection” and “Audit Filtering Platform Connection” logs may extensive amount of information to the Windows security Eventlog for both successful and failed connections allow or blocked by the Windows Filtering Platform. Microsoft Windows 7 / Windows 2008 R2 introduces 53 new policies that isn't always preferred to have enabled. The default settings within Windows 7 is to have most of these policies enabled.
The “Audit Filtering Platform Connection” and “Audit Filtering Platform Packet Drop” policies are enabled if you have defined the "Object Access" auditing function within group policies for either/both failure and success. With that said you are now able to manage these policies more specific under Windows 2008 R2. See this TechNet article for more information: http://technet.microsoft.com/en-us/library/dd772712(WS.10).aspx
Here is how you get rid of the mass flooding of Event ID 5156 - The Windows Filtering Platform has allowed a connection within the Event Log
I would recommend that the WFP be disabled using either scripting or group polices.
Scripting
To manually configure the changes to the Windows auditing function. You verify the problem you can use the Microsoft Auditpol tool that allows for changing the Windows auditing policies.
"auditpol /set /subcategory:”Filtering Platform Connection” /success:disable /failure:disable"
"auditpol /set /subcategory:”Audit Filtering Platform Packet Drop” /success:disable /failure:disable"
Executing these commands changes the setting to disabled auditing for the Filtering Platform Connection and Audit Filtering Platform Packet Drop.
Verify the setting with "auditpol /get /subcategory:”Audit Filtering Platform Packet Drop”
For more information check these articles:
http://msdn.microsoft.com/en-us/library/bb309058(VS.85).aspx
Group Policies
1. Open the Group Policy Management Console and create a new Group Policy called "Advanced Client Auditing" (Or use existing).
2. Modify the group policy and configure the settings for auditing.
3. Verify that the console user appears in the SCCM report after a hour (Group Policy refresh is usaually 15min + replication)
For more information check these articles:
http://technet.microsoft.com/en-us/library/ee513968(WS.10).aspx.
Links
(Asset Intelligence Client Access License (CAL) reports do not contain data):
http://technet.microsoft.com/en-us/library/cc431411.aspx
Hi UAG folks,
During a deployment of UAG 2010 in a test lab I bumped into a small issue with getting UAG to update the GPO policies in Active Directory.
When you click "Apply Now" and execute the Poweshell it will output within the UAG console and you might get an error if you use special characters in either your username or "%TEMP%" user environment variable.
It doesn't seem that the script was build with support for error handling and expecting special characters within the %TEMP% variable.
The error you might get..
failed. Windows cannot open the file named c:\users\\AppData\Local\Temp\...... 
Workaround/Fix
To get around this issue the easy way is to change the %TEMP% variable. You could decide to use a more normal username that doesn't include special characters... 
Changing the %TEMP% variable.
See this Microsoft KB article for more information.
http://support.microsoft.com/kb/310519
Powershell and Special Chars:
http://msdn.microsoft.com/en-us/library/dd878238(VS.85).aspx
Peter Dahl