Most Recent Posts
May 13,2013 by Configuration Manager 2012 SP1 CU1 Half-Baked InstallIt appears an installation of ConfigMgr 2012 SP1 Cumulative Update 1 (KB2817245), if the pre-1/25/13 SP1 media is used and the KB2801987 hotfix applied, doesn’t necessarily play nice.
Working on some scripts in the lab, I attempted to use PowerShell to import some computer information, literally copying and pasting the sample code from the Import-CMComputerInformation TechNet article and substituting a custom collection. I was greeted with the following error:
WARNING: The collection OSD Management does not exist or is not suitable for adding the new device.
Some quick research revealed that this was a known bug in the SP1 PowerShell cmdlets that was fixed with CU1:
OK, great. Easy fix. I knew I hadn’t updated my hydration build with CU1 yet and had just rebuilt the lab two weeks ago, so I grabbed the CU1 install and ran the update…
Wait…what do you mean, “This update has already been installed on this system.”? And where did KB2801987 come from…I thought I was installing KB2817245, not just the hotfix for the MicrosoftPolicyPlatformSetup.msi error? Now that I think about it, my hydration kit had been built with the “oops” release of the SP1 media, so I did install KB2801987 on the server to fix OSD issues. Anyway, I look in both the regular Programs and Features list and the View Installed Updates list…no sign of either KB. Let’s see what the log says…
Pull it up in regedit and sure enough, there it is:
Basically, we have two options at this point: uninstall KB2801987 and then install CU1 (KB2817245), or extract a what we need from the latter and apply it separately. I highly recommend the former.
Method 1 – Clean Install
Using the UninstallString from the registry information, I removed KB2801987 and then ran the CU1 update again. This time the prereq check passed and I was able to walk through the entire install. This ensured that the full update installation went through and all relevant issues to the CU were fixed.
Method 2 – Just give me my working cmdlets
Initially, I just wanted to get the cmdlets working, so I discovered through a little poking around that the AdminConsole update may need to be manually run (see post by Kaido1000) in some instances. So I extracted the CU1 executable, ran an administrative install of the configmgr2012-sp1-cu1-kb2817245-x64-enu.msi file, and grabbed the configmgr2012adminui-sp1-kb2817245-i386.msp file.
So, with either method accomplished, we’re ready to run our Import-CMComputerInformation cmdlet again and create our computer.
Yeah…not quite. We run the same command, and we definitely get a different result:
Import-CMComputerInformation : A parameter cannot be found that matches parameter name ‘SmsBiosGuid’.
Well, the patch definitely changed something. Did they change the parameters of the cmdlet?
Interesting…so with SP1 the parameter is -SmsBiosGuid and with CU1 it’s now -SmBiosGuid. Hopefully Microsoft will get the online reference updated at some point.
Run it again with the new parameter…
…and finally we have what we came for.
- Phil Schwan, Technical Specialist
You can read more posts by Phil at My IT Forum.
Comments(0) Add a Comment
Using ConfigMgr to deploy the UE-V agent can present a nasty surprise if you try to specify the SettingsStoragePath using the %USERNAME% environment variable.
Microsoft released the User Experience Virtualization (or UE-V) agent with MDOP 2012 as a means of ensuring a consistent user experience across multiple devices, providing yet another tool to put to rest the pain that is “roaming profiles.” The premise is simple: use XML files to store application settings and leverage the built-in Offline Files engine to sync them for reference between multiple machines. No more going through all your favorite customizations in Microsoft Word to make it look the same on all your machines or virtualized instances; now your settings can follow you.
Obviously, this means you need a central storage location (Settings Storage Path) for these settings XML files. If you have your AD user accounts configured with home folders, this process is super easy: the UE-V agent will automatically detect and use the home folder as the Settings Storage Path without any need for further configuration.
However, if you don’t have home folders configured, or want to use an alternate location for storage, there are several methods of controlling this. You can use the UE-V Group Policy ADMX Templates to configure the Settings Storage Path, you can use PowerShell to configure the agent with the installed PowerShell module, or you can set the path at install time using the SettingsStoragePath install property (the actual storage path is stored in the registry).
Typically, the assigned storage path leverages the %USERNAME% environment variable in order to automatically create and secure a subfolder in the storage location for the user. However, if you are deploying the UE-V agent with Configuration Manager and attempting to set the SettingsStoragePath property using the %USERNAME% variable there is a catch. If we set the property using %USERNAME% in the ConfigMgr command line (ex – SettingsStoragePath=\\server\share\%USERNAME%)…
…we get an unexpected result for our storage location…
This is because ConfigMgr evaluates the environment variable as it builds the command line, and because the installation is running in the SYSTEM context the %USERNAME% variable is replaced by “SYSTEM”
That property in turn gets written to the HKLM UE-V agent configuration in the registry…
…meaning not only all users of that machine will point to the same settings storage location, but all other machines that ConfigMgr installs the UE-V agent on using this command line will point to the same one. Not a good thing!
Fortunately, there is a way we can prevent ConfigMgr from evaluating the variable by taking advantage of how Windows interprets command lines. By adding a caret (^) character in front of the % character, ConfigMgr doesn’t see it as anything needing evaluation. In turn, Windows will treat the character following the caret as a standard character and include it in the execution as if it were a normal string, stripping out the carets at execution time. So if we modify our Deployment Type to use ^%USERNAME^% in the command line (ex – SettingsStoragePath=\\server\share\^%USERNAME^%)…
…we see that the command line is properly built…
…the registry entry is now written correctly…
…and the UE-V agent uses a settings storage location corresponding to the username of the currently logged in user!
- Phil Schwan, Technical Specialist.
You can read more posts by Phil at My IT Forum.
Comments(1) Add a Comment
Often times Project Managers have to communicate project plan details to different teams with different levels of details. For example, the tasks and milestones a development team is interested in will be different from the milestones a leadership would be looking to review.
Instead of manually developing a timeline chart using Visio or Excel for each team, Project Managers can develop custom Timelines for their audience using Microsoft Project 2010.
Pre Requisites:
1. MS Project 2010
2. A project plan in Project 2010 format.
How to create a custom Timeline?
- 1. Click on View tab and under Task Views group, select Other View. Select More Views from the dropdown.
- For the Name field, provide a name you would like to use for the Timeline. For example: Executive Timeline.
- For the Screen field, select Timeline
- Select Show in menu checkbox
- Click Ok
2. A More Views pop up will be displayed. Click New, select Single View and click Ok.
3. A View Definition pop up will be displayed.
4. On More Views window, click Ok.
You have now successfully created a Timeline which should be displayed under the More Views dropdown.
Adding tasks to the Timeline
- 1. Under Other Views, click on Executive Timeline. Executive Timeline will be displayed.
Note: The Timeline by default will be empty and you will need to add tasks to it.
2. Right click and select Existing Tasks as shown below.
3. Add Tasks to Timeline window will be displayed. Select the tasks you want to add to the Timeline and click Ok.
- Sri Tulasiram, Managing Consultant
Comments(1) Add a Comment
Auditing has become the new focus in Exchange 2010. In my last article I covered Mailbox Auditing. Something new that was added to Exchange 2010 was Admin Audit logging.
What is Admin Audit Logging? “You can use administrator audit logging in Microsoft Exchange Server 2010 to record actions taken by a user or administrator that make changes in your organization. By keeping a log of the changes, you can trace a change to the person who made it. You can also augment your change logs with detailed records of the change as it was implemented, use the records to comply with regulatory requirements and requests for discovery, and so on.”
By default Admin Audit logging is enabled and auditing your administrators actions in Exchange 2010. What if you wanted to generate a report on it, how would you handle this? Below is a sample script I use for this purpose:
# Load the Exchange PowerShell SnapIns in case this is run on a non Exchange Server
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 # Adds the Exchange 2010 Snapin
#Set date parameters for the scripts
$Days = "14" #How many days history of the log file do you want to send?
$now = (Get-Date).ToString("MM-dd-yyyy") # Today's date
$StartDate = ((Get-Date).AddDays(-$Days).ToString("MM-dd-yyyy")) # Start date for search
# Configure path locations
$serverpath = "\\servername\sharename\" #remote path to copy the XML file to
$localpath = "C:\Scripts\exchangelogging\" #local working directory where the XML file will initially be exported to
$xmlfile = "MailboxAdminAuditLog" + $now + ".xml"
$localfile = $localpath + $xmlfile
$subject = "Exchange Admin Audit Log " + $now
$recipients = "<IT Admin email address>"
$body = "The latest Exchange Admin Audit Log is now available at: " + $serverpath + $xmlfile
Search-AdminAuditLog -StartDate $StartDate -EndDate $now | Export-Clixml $localfile
copy-item $xmlfile $serverpath
Send-MailMessage -to $recipients -from "<IT Dept Email Address>"-SmtpServer <Valid SMTP server> -Subject $subject -Body $body
remove-item $localfile
So what does this script do?
- Line 2 – Loads the Exchange 2010 PowerShell snap-in in case its needed
- Lines 4-7 – Sets the date range with a current date and start date
- Lines 9-12 – set paths for local and remote file storage
- Lines 16,17 – sets subject and recipients for emailed report
- Line 19 – Configures body of the report email
- Line 21 – exports the audit log to a file
- Line 23 – copies the file to the remote server location for storage
- Line 25 – sends email out to IT admins
- Line 27 – removes local files for cleanup
After the script is executed you are now left with an XML file to use for reviewing the information contained in the logs.
Technet Articles
http://technet.microsoft.com/en-us/library/dd335052(v=exchg.141).aspx
- Damian Scoles, Technical Architect
You can read more posts by Damian at Just a UC Guy.
Comments(1) Add a Comment
If you work for a firm in the financial industry (trading, insurance, etc) you know that auditing is a part of life. Sometimes this is because your company is public or required by law to do so, sometimes its because you have an internal auditing process initiated by internal procedures. Exchange 2010 has two kinds of logs for auditing and they are Admin Auditing and Mailbox Auditing. This article is concerned with the latter of the two types of logging.
What exactly is Mailbox Auditing? Mailbox auditing is the tracking of specific types of actions (accessing, moving, or deleting a message, etc) by logon type (administrator, delegate user, or owner). Using this kind of auditing will allow you to find out who manipulated another users mailbox or simply accessed their email.
How would you generate a report for this?
Here is a sample Script I’ve been using:
# Load the Exchange PowerShell SnapIns in case this is run on a non Exchange Server
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 # Adds the Exchange 2010 Snapin
#Set Date parameters for the scripts
$Days = "7" #How many days history of the log file do you want to send?
$current = (Get-Date).ToString("MM-dd-yyyy") # Today's date
$StartDate = ((Get-Date).AddDays(-$Days).ToString("MM-dd-yyyy")) # Start date for search
# Configure path locations
$serverpath = "\\servername\sharename" # Remote location for reports
$localpath = "C:\scripts\exchangelogging"
$xmlfile = "MailboxAuditLog" + $current + ".xml"
$localfile = $localpath + $xmlfile
$subject = "Exchange Admin Audit Log " + $now
$recipients = "<IT Admin SMTP Address>"
$body = "The latest Exchange Admin Audit Log is now available at: " + $serverpath + $xmlfile
Search-MailboxAuditLog -StartDate $StartDate -EndDate $now | Export-Clixml $localfile
copy-item $xmlfile $serverpath
Send-MailMessage -to $recipients -from <IT Department email address> -SmtpServer <valid SMTP server> -Subject $subject -Body $body
remove-item $localfile # Cleans up after itself.
This script basically will run the audit and send an email to the auditors who need to review the information that has been captured by mailbox auditing.
Quick explanation of the code.
- Line 2 – Loads the Exchange 2010 PowerShell snap-in in case its needed
- Lines 4-7 – Sets the date range with a current date and start date
- Lines 9-12 – set paths for local and remote file storage
- Lines 16,17 – sets subject and recipients for emailed report
- Line 19 – Configures body of the report email
- Line 21 – exports the audit log to a file
- Line 23 – copies the file to the remote server location for storage
- Line 25 – sends email out to IT admins
- Line 27 – removes local files for cleanup
After the script is executed you are now left with an XML file to use for reviewing the information contained in the logs.
Technet Articles
http://technet.microsoft.com/en-us/library/ff522360(v=exchg.141).aspx
- Damian Scoles, Technical Architect
You can read more posts by Damian at Just a UC Guy.
Comments(0) Add a Comment