Archive

Author Archive

SCCM SUP in an offline environment

July 9th, 2009 Udi Leutashi 2 comments

If you had to maintain a SCCM server in an offline environment you know it’s not a simple task. One of the steps you have to carry out is to download all the updates from the Internet or to copy them from another WSUS/SCCM SUP server that is connected to Internet and had already downloaded all the updates.

For the first method you can use this great post:

http://myitforum.com/cs2/blogs/jgilbert/archive/2008/10/28/getting-required-updates-on-non-internet-connected-sups-part-1.aspx

and part 2:

http://myitforum.com/cs2/blogs/jgilbert/archive/2008/10/28/getting-required-updates-on-non-internet-connected-sups-part-2.aspx

If you have another WSUS/SCCM SUP server that is online, the easiest way to get those updates is to copy them from the server. This is where it gets a little bit tricky:

The updates are found in the “WSUSContent” folder or in SCCM’s case in a folder share of your choice, the only problem is that they are scattered in different folders, This causes a problem because when you’ll need to provide the offline WSUS/SCCM SUP with the updates they will have to be in a single folder. For this purpose I found a little batch file that will get the job done (Credit goes to Rems):

@echo off
title WAIT !

Set "sourceDir=c:\1234"
Set "destinationFolder=c:\SHOEBOX"
Set "_report=c:\logxcopy.txt"

IF NOT EXIST "%sourceDir%" (echo.Could not find %sourceDir% &GoTo:done)

:: overwrite previous log
>"%_report%" (
      echo.%date% - %time%
      echo.---------------------------------------------------
      echo.
)

:: copy files
For /F "Delims=" %%! in ('Dir "%sourceDir%\" /b /s /a-d 2^>nul') do (
   @echo.%%! &(
   @xcopy "%%!" "%destinationFolder%\" /i /y /h /f /c >>"%_report%",2>&1)
)

:done
title,Done.......

echo.&pause>nul

This batch will copy all the files from a folder tree to a single folder.

More info about offline WSUS/SCCM SUP environment:

http://technet.microsoft.com/en-us/library/cc720512(WS.10).aspx

http://myitforum.com/cs2/blogs/jgilbert/archive/2008/10/19/synchronizing-non-internet-connected-software-update-points.aspx

Enjoy!

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]

OpsMgr 2007: What if I lose my RMS encryption key!?

July 9th, 2009 Udi Leutashi No comments

If Your RMS had failed prior to Service Pack 1, and you didn’t have a backup of your encryption key, You were in trouble. Your only option was to rebuild from scratch.

Now with SP1, we have a new CREATE_NEWKEY command line switch that can make recovering from a situation like this potentially much easier. We also made running the encryption key backup process a mandatory process of setup, just so you’ll have a friendly reminder.

So let’s take a look at a couple scenario’s:

1.  The Root Management Server is replaced or reinstalled and the key is not backed up or the password to the key is lost. There are no other Management Servers to promote.

Solution: Install a new Management Server (the RMS replacement) and be sure the computer name is the same name as the previous Root Management Server that is being replaced.  Setup will detect that the machine name is same as the Root Management Server in the database so it will recreate a new key and register the licenses.

2.  The Root Management Server is replaced or reinstalled and the key is not backed up or the password to the key is lost. There is at least one Management Server to promote to Root Management Server.

Solution: On the Management Server that will become the new Root Management Server, run MOM.msi with the CREATE_NEWKEY switch (msiexec.exe /i <Path to MOM.msi> CREATE_NEWKEY=1).  Configure the account for SDK/Config services (this account should have permission to the database, the SDK service account should be added to the SDK_users role, and the config service account should be added to the configsvc_users role).  Promote the Management Server to Root Management Server.

3.  The registry on the Root Management Server got corrupted, thus the encryption key is lost.
Solution: Run MOM.msi with special switch (msiexec.exe /i <Path to MOM.msi> CREATE_NEWKEY=1)

So does this mean you don’t have to worry about backing up your keys?  No, you should always backup your keys and keep them in a safe place as doing so will potentially save you a lot of trouble down the road, but now if something happens there’s possibly a way to recover without having to rebuild.

Backing up your RMS encryption key: http://technet.microsoft.com/en-us/library/bb309563.aspx.

 

(Taken from: The Manageability Team Blog-http://blogs.technet.com/smsandmom/archive/2007/12/05/opsmgr-2007-what-if-i-lose-my-rms-encryption-key.aspx)

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]
Categories: SCOM, System Center Tags: , ,

SCCM: Organize your software updates deployment

July 9th, 2009 Udi Leutashi No comments

The Search Folders that come with the software update point role in SCCM, provide an easy  and comfortable way to keep track of you’re update deployment status.

I personally use 3 folders to keep track of my updates status “All Updates”, “Deployed Updates” and “New Updates” , In this post I’ll show you how you can create them yourself.

image

Creating a search folder is very easy, just right click the “Search Folder” node and select “New Search Folder”, Now all you have to do is give it a name and specify it’s criteria:

1. “All Updates” – This will give you a view of all the the updates that are listed in your repository.

Criteria:

Update Classification – Choose all

Expired – Choose “No”

Mark the “Search all folders under this feature” checkbox

2. “Deployed Updates” – This will give you an idea of what updates are currently included in your software update deployment.

Criteria:

Update Classification – Choose all (or what interest you)

Deployed – Choose “Yes”

Mark the “Search all folders under this feature” checkbox

3. “New Updates” – This will give you an idea of what new updates were released and are not yet included in your software update deployment.

Criteria:

Update Classification – Choose all (or what interest you)

Deployed – Choose “No”

Expired – Choose “No”

Mark the “Search all folders under this feature” checkbox

 

That’s all there is to it. Enjoy!

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]

Windows Server 2008 SP2 has been released and is supported for Exchange 2007

July 8th, 2009 Udi Leutashi No comments

Exchange 2007 is supported on Windows 2008 SP2. This will be also true for the upcoming Exchange 2007 SP2, when it releases.

Hardware ecosystem support and enhancements
  • SP2 adds support for the 64-bit central processing unit (CPU) from VIA Technologies, which adds the ID and vendor strings for the new VIA 64-bit CPU.
  • SP2 integrates the Windows Vista Feature Pack for Wireless, which contains support for Bluetooth v2.1 and Windows Connect Now (WCN) Wi-Fi Configuration. Bluetooth v2.1 is the most recent specification for Bluetooth wireless technology.
  • SP2 improves performance for Wi-Fi connections after resuming from sleep mode.
  • SP2 includes updates to the RSS feeds sidebar for improved performance and responsiveness.
  • SP2 includes ability to record data to Blu-Ray Disc media.
Operating system experience updates
  • SP2 includes Windows Search 4.0, which builds on Microsoft’s search technology with improved indexing and search relevance. It also helps find and preview documents, e-mail (including signed e-mail messages), music files, photos, and other items on the computer. The search engine in Windows Search 4.0 is a Microsoft Windows® service that is also used by programs such as Microsoft Office Outlook® 2007 and Microsoft Office OneNote® 2007. Autotuning Diagnostics in SP2 now interprets current network conditions when implementing Windows scaling. This feature includes full netsh support.
  • SP2 improves Windows Media Center (WMC) in the area of content protection for TV.
  • SP2 removes the limit of 10 half open outbound TCP connections. By default, SP2 has no limit on the number of half open outbound TCP connections.
Enterprise improvements
  • SP2 provides the Hyper-V virtualization environment as a fully integrated feature of Windows Server 2008, including one free instance with Windows Server 2008 Standard, four free instances with Windows Server 2008 Enterprise and an unlimited number of free instances with Windows Server 2008 Datacenter.
  • SP2 increases the authentication options for WebDAV redirector, enabling Microsoft Office users greater flexibility when authenticating custom applications using the WebDAV redirector.
  • SP2 provides an improved power management (both on the server and the desktop), which includes the ability to manage these settings via Group Policy.
  • SP2 improves backwards compatibility for Terminal Server license keys. Windows Server 2008 changed the licensing key from 512 bytes to 2,048 bytes which caused clients using older Terminal Server versions to fail. SP2 allows legacy license keys on Citrix applications to work with Windows Server 2008 Terminal Server.
Setup and deployment improvements

The SP2 standalone installer:

  • Provides a single installer for both Windows Vista and Windows Server 2008.
  • Includes the ability to detect an incompatible driver and either block service pack installation or warn users of any potential loss of functionality.
  • Provides better error handling and descriptive error messages where possible.
  • Improves manageability through logging in the system event log.
  • Provides a secure install experience.
  • Includes the ability to service the installer post release.

SP2 also includes a Service Pack Clean-up tool (Compcln.exe) which helps recover the hard disk space by permanently deleting previous versions of files (RTM and SP1) that are being serviced by SP2. The Service Pack Clean up tool can also be run offline while creating slipstream images to reduce the size of the image.

SP2 Download is available here:

x86

x64

Thanks to Tonino Bruno for this info.

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]

How-To: Exchange 2007 Managed Folder Policies

July 7th, 2009 Udi Leutashi No comments

In previous versions of Exchange a number of mailbox management settings where handled by the RUS (recipient update service). Exchange 2007 has changed the way the users mailboxes are managed and Microsoft has taken more time to work Email Life Cycle (ELC) into Exchange 2007.

In this article I am going to deploy some default folder management (inbox,deleted items, etc) and add some new custom folder management policies for my users.

As with most features with Exchange 2007 this can be deployed via EMS (command line) or EMC (GUI). I will attempt to move back and forth between these methods to show their capabilities.

Default folder management

Lets launch EMC—> Organizational config –>Mailbox

Here we can see a number of tabs and I am going to focus on the default folder management tab. After selecting the tab we can see default Outlook folders items such as inbox, deleted items, etc…

Lets create a policy for one of my favorite areas to manage, deleted items. Over the years I have found that users use their deleted items folder as almost an archive for their mailbox, I never understood this but hey :P

Let create a new managed content settings for deleted items.

1. Select Deleted Items
2.right click the screen and select new managed content settings

There are a number of options to set on the first page,
– Message Type , Retention period date,action, and length of retention

Message Type allows us to define what type of content we want this policy to apply to, since we are dealing with deleted items I want to set to All Mailbox Content.

The Action lets of define what we want to do and for this policy I want to delete and allow recovery

Retention period start tells the policy what is should base its information on, either date the item was moved to a folder or the date the item was received/created

Here we can see the first page completed

The next page allows us to journal a copy of the content to a specified location

The next page provides us with the settings that we have chosen

The completion page show the powershell command used to create the new management settings

At this point all we have done is create the management settings, by its self this does nothing but create a template for us to use in a policy.

Managed Folder Policy
The policy will use the new created management settings that we have created.

1. Select the Managed Folder Policy tab
2. Right click the screen and select New Managed Folder Mailbox Policy

The first page of wizard allows us to specify a name for the policy and then add a component to manage.

After selecting the Add button we see a list of items that we can manage. Note not all of them have managed content setting created at this time but the policy will allow you to add the anyway.

After selecting deleted items we are brought back to the original screen –> New

The completion page show the powershell commands used to create the policy –> finish

Now that we have 1. created managed content settings and 2. created a managed folder mailbox policy we have 2 more steps before our policy becomes functional.

By default the mailbox management assist is set to never run, we need to enable this and set a schedule for the process to run and enforce our policy.

From EMC — Server –Mailbox right click on the mailbox server and select properties

Select the Messaging Records Management tab and you will see the default of never run

Select Customize and choose the appropriate hours for the process to run

After we have created a schedule for the mailbox assistant to run the last remaining step is to associate the policy with user mailbox.

For large amounts of users utilizing powershell would be the preferred way to deploy this, however since I am going to set this for 1 user I am going to use EMC.

In EMC select Recipient Configuration –> Mailbox
double click the mailbox and select Mailbox Settings

Select Messaging Records Management then click properties

check the Managed Folder Mailbox Policy and browse to the correct policy for the user

In order to apply policy to all users mailbox use:

Get-Mailbox -ResultSize unlimited | Set-Mailbox -ManagedFolderMailboxPolicy “Purge Deleted Items”

In order to apply policy to members of a OU use:

Get-User -OrganizationalUnit “OU1″ | Set-Mailbox -ManagedFolderMailboxPolicy “Purge Deleted Items”

In order to apply policy to members of a distribution list use:

get-distrobutiongroupmember group1 | Set-Mailbox -ManagedFolderMailboxPolicy “Purge Deleted Items”

We have now completed the last step and our policy will take affect the next time the mailbox assistant runs.

We can use powershell to force an update if we want to apply the policy immediately(very useful for testing):
Start-ManagedFolderAssistant -identity mailboxservername

(Based on: http://www.exchange-genie.com/2007/11/managed-folder-policies/)

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]

Understanding the Move Date in Messaging Records Management (MRM)

July 7th, 2009 Udi Leutashi No comments

Exchange 2007′s Messaging Records Management (MRM) feature is designed to help your organization manage messages for compliance purposes.  By using Managed Content Settings, users can have their messages moved to different folders or deleted automatically, based on age.  You also have the option to Journal these messages to any SMTP address, which is ideal for many third-party archiving systems.

One thing I’ve been finding in my cases is that many customers don’t understand the Retention Period settings and how they are applied by the Managed Folder Assistant.  Let’s take a look at a simple example to try and make this point.  Here is a typical mistake that many people make:

image

In this example, the Retention Period is set to start When item is moved to the folder.  Most of the time, people decide to choose this option because they want to apply the action to items that were either delivered to the folder or moved to the folder by the user 30 days ago.  When they add these settings to a policy and apply it, they are surprised to find that the items do not get archived.  The policy is actually working correctly in this case, but we need to understand what it is doing.

When you choose “When item is moved to the folder” as the start of the Retention Period, the retention period doesn’t actually start until the next time the Managed Folder Assistant runs.  This is explained in the TechNet article regarding how Retention Periods are calculated:

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

What the article does not explain is what the move date is.  The move date is actually a MAPI property named ElcMoveDate.  The “Elc” in ElcMoveDate stands for Exchange Lifecycle Assistant, another name for the Managed Folder Assistant.  This property is viewable by its property number (0×67170102) in MFCMapi:

image

This property will not be present at all until the Managed Folder Assistant has run on the folder and stamped the item.  The first time the Managed Folder Assistant runs, it stamps every item with the ElcMoveDate property and the current timestamp.  It will not delete any items at that point, unless there was somehow an existing item with an ElcMoveDate outside the retention period.  In subsequent runs, the Managed Folder Assistant will evaluate each item and determine if its ElcMoveDate is beyond the Retention Period.  If so, the Action specified by the Managed Content Settings for the folder will be taken.

Continuing the example from above, if the “Inbox 30 day retention” settings are applied to a user’s mailbox, here is the sequence that would occur:

1.  Managed Folder Assistant runs for the first time on January 1 at 8:00am.  No items in the Inbox currently have an ElcMoveDate stamped, so all are stamped with the current date and time.

2.  Managed Folder Assistant continues to run daily for the next 29 days, moving no items.

3.  Managed Folder Assistant runs on January 31 at 8:00am.  All the items stamped on January 1 are now moved to the Deleted Items folder, because the ElcMoveDate is now 30 days in the past.

The confusion arises because there were very likely items in the Inbox on January 1 that were received or even moved there by the user in November, for example.  The administrator normally expects those items to be moved immediately.  Now you can see why this is not the case.

If you’re looking to do archiving based on the date a message was received, you should choose  When delivered, end date for calendar and recurring tasks in the “Retention period starts” box.  When this is chosen, items are processed just as the setting implies:  everything except for Calendar items and recurring Tasks is processed based on message-received date.  Calendar items and recurring Tasks are processed based on the end date of the item.

Typically, the When item is moved to the folder setting is only placed on a folder that you are using as a Destination in your Managed Content Settings.  So, you would normally set the Inbox to start the retention process when items are delivered.  You would then set the Deleted Items folder to process based on when an item is moved to the folder.  This would allow you to have actual 30 day retention on the Inbox and allow, say, another 14 days once the item is moved to Deleted Items before it is permanently deleted.

Here again is a link to the TechNet article mentioned above.  Please review it carefully, as it explains in detail the rest of the retention period process:

How Retention Periods Are Calculated for Items in Managed Folders

 

(Taken from: Dale Hardin blog – http://blogs.technet.com/dhardin/archive/2009/05/25/understanding-retention-periods-for-messaging-records-management-mrm.aspx)

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]
Categories: Exchange 2007 Tags: , ,

Force Remove OPS 2007 Agent

July 6th, 2009 Udi Leutashi No comments

If you tried uninstalling OPS 2007 agent and got an error, You should try the following:

1. Run “cleanMOM.exe /cleanagents” on the client. This will not completely uninstall the agent but it will let you reinstall it so you can then uninstall it

2. Install OPS 2007 agent with a different management group name (the name doesn’t really matter).

3. Uninstall OPS agent, It should uninstall fine. If not redo steps 1 and 2 again.

4. If the “Health Service” hadn’t been uninstalled run:

sc delete “HealthService

5. If the “Audit Forwarding Service” hadn’t been uninstalled run:

sc delete “AdtAgent

6. Delete the client from the OPS console (It should look grayed out):

Administration -> Agent managed -> Select client -> Right click -> Delete

That’s it, you’re done.

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]

Moving WSUS Server Updates Folder

July 6th, 2009 Udi Leutashi 1 comment

If you’re using Microsoft Windows Server Update Services (WSUS), there may come a day when you need to move the updates to another drive. Once WSUS has been installed, the WSUS Administration tool doesn’t let you do this, but you can do it using a command line tool called wsusutil found in C:\Program Files\Update Services\Tools. I’m running version 3.0 SP1.

The command is:

wsusutil movecontent logfile.log x:\WSUS

(where x: is the new destination)

If you have already copied the content (make sure you’ve set the correct permissions), you can run:

wsusutil movecontent logfile.log f:\WSUS -skipcopy

NOTE: This is separate to the WSUS database itself, this only applies to the actual patches.

To see the other uses of wsusutil, run it with no arguments:

C:\Program Files\Update Services\Tools>wsusutil.exe
Windows Server Update Services administration utility. Try:
wsusutil.exe help checkhealth
wsusutil.exe help configuressl
wsusutil.exe help configuresslproxy
wsusutil.exe help deletefrontendserver
wsusutil.exe help listinactiveapprovals
wsusutil.exe help removeinactiveapprovals
wsusutil.exe help export
wsusutil.exe help healthmonitoring
wsusutil.exe help import
wsusutil.exe help listfrontendservers
wsusutil.exe help movecontent
wsusutil.exe help reset
wsusutil.exe help usecustomwebsite
wsusutil.exe help listunreferencedpackagefolders

 

(Taken from: http://www.chrisburgess.com.au/moving-wsus-server-updates/)

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]
Categories: SCCM, WSUS Tags: , , ,

The full and complete list of SCCM Log Files

July 2nd, 2009 Udi Leutashi No comments

SCCM uses a lot of log files, it could be quite confusing finding what you need. I gathered a list of all the log files and a description of their content to make life easy.

The client logs are located in the %WINDIR%\System32\CCM\Logs folder or %WINDIR%\SysWOW64\CCM\Logs (for x64 OS).
The SCCM server log files are located in the <INSTALL_PATH>\Logs or SMS_CCM\Logs folder.

IIS logs can be found in %WINDIR%\System32\logfiles\W3SVC1 folder.

NOTE: Use the Trace tool included in the SCCM Toolkit or MS Log Parser to easily view log files.

 

Client Log Files

  • CAS – Content Access Service. Maintains the local package cache.
  • Ccmexec.log – Records activities of the client and the SMS Agent Host service.
  • CertificateMaintenance.log – Maintains certificates for Active Directory directory service and management points.
  • ClientIDManagerStartup.log – Creates and maintains the client GUID.
  • ClientLocation.log – Site assignment tasks.
  • ContentTransferManager.log – Schedules the Background Intelligent Transfer Service (BITS) or the Server Message Block (SMB) to download or to access SMS packages.
  • DataTransferService.log – Records all BITS communication for policy or package access.
  • Execmgr.log – Records advertisements that run.
  • FileBITS.log – Records all SMB package access tasks.
  • Fsinvprovider.log (renamed to FileSystemFile.log in all SMS 2003 Service Packs) – Windows Management Instrumentation (WMI) provider for software inventory and file collection.
  • InventoryAgent.log – Creates discovery data records (DDRs) and hardware and software inventory records.
  • LocationServices.log – Finds management points and distribution points.
  • Mifprovider.log – The WMI provider for .MIF files.
  • Mtrmgr.log – Monitors all software metering processes.
  • PolicyAgent.log – Requests policies by using the Data Transfer service.
  • PolicyAgentProvider.log – Records policy changes.
  • PolicyEvaluator.log – Records new policy settings.
  • Remctrl.log – Logs when the remote control component (WUSER32) starts.
  • Scheduler.log – Records schedule tasks for all client operations.
  • Smscliui.log – Records usage of the Systems Management tool in Control Panel.
  • StatusAgent.log – Logs status messages that are created by the client components.
  • SWMTRReportGen.log – Generates a usage data report that is collected by the metering agent. (This data is logged in Mtrmgr.log.)


Server Log Files

  • Ccm.log – Client Configuration Manager tasks.
  • Cidm.log – Records changes to the client settings by the Client Install Data Manager (CIDM).
  • Colleval.log – Logs when collections are created, changed, and deleted by the Collection Evaluator.
  • Compsumm.log – Records Component Status Summarizer tasks.
  • Cscnfsvc.log – Records Courier Sender confirmation service tasks.
  • Dataldr.log – Processes Management Information Format (MIF) files and hardware inventory in the Configuration Manager 2007 database.
  • Ddm.log – Saves DDR information to the Configuration Manager 2007 database by the Discovery Data Manager.
  • Despool.log – Records incoming site-to-site communication transfers.
  • Distmgr.log – Records package creation, compression, delta replication, and information updates.
  • Hman.log – Records site configuration changes, and publishes site information in Active Directory Domain Services.
  • Inboxast.log – Records files that are moved from the management point to the corresponding SMS\INBOXES folder.
  • Inboxmgr.log – Records file maintenance.
  • Invproc.log – Records the processing of delta MIF files for the Dataloader component from client inventory files.
  • Mpcontrol.log – Records the registration of the management point with WINS. Records the availability of the management point every 10 minutes.
  • Mpfdm.log – Management point component that moves client files to the corresponding SMS\INBOXES folder.
  • MPMSI.log – Management point .msi installation log.
  • MPSetup.log – Records the management point installation wrapper process.
  • Ntsvrdis.log – Configuration Manager 2007 server discovery.
  • Offermgr.log – Records advertisement updates.
  • Offersum.log – Records summarization of advertisement status messages.
  • Policypv.log – Records updates to the client policies to reflect changes to client settings or advertisements.
  • Replmgr.log – Records the replication of files between the site server components and the Scheduler component.
  • Rsetup.log – Reporting point setup log.
  • Sched.log – Records site-to-site job and package replication.
  • Sender.log – Records files that are sent to other child and parent sites.
  • Sinvproc.log – Records client software inventory data processing to the site database in Microsoft SQL Server.
  • Sitecomp.log – Records maintenance of the installed site components.
  • Sitectrl.log – Records site setting changes to the Sitectrl.ct0 file.
  • Sitestat.log – Records the monitoring process of all site systems.
  • Smsdbmon.log – Records database changes.
  • Smsexec.log – Records processing of all site server component threads.
  • Smsprov.log – Records WMI provider access to the site database.
  • SMSReportingInstall.log – Records the Reporting Point installation. This component starts the installation tasks and processes configuration changes.
  • SMSSHVSetup.log – Records the success or failure (with failure reason) of installing the System Health Validator point.
  • Srvacct.log – Records the maintenance of accounts when the site uses standard security.
  • Statmgr.log – Writes all status messages to the database.
  • Swmproc.log – Processes metering files and maintains settings.


Admin Console Log Files

  • RepairWizard.log – Records errors, warnings, and information about the process of running the Repair Wizard.
  • ResourceExplorer.log – Records errors, warnings, and information about running the Resource Explorer.
  • SMSAdminUI.log – Records the local Configuration Manager 2007 console tasks when you connect to Configuration Manager 2007 sites.


Management Point Log Files

  • MP_Ddr.log – Records the conversion of XML.ddr records from clients, and copies them to the site server.
  • MP_GetAuth.log – Records the status of the site management points.
  • MP_GetPolicy.log – Records policy information.
  • MP_Hinv.log – Converts XML hardware inventory records from clients and copies the files to the site server.
  • MP_Location.log – Records location manager tasks.
  • MP_Policy.log – Records policy communication.
  • MP_Relay.log – Copies files that are collected from the client.
  • MP_Retry.log – Records the hardware inventory retry processes.
  • MP_Sinv.log – Converts XML hardware inventory records from clients and copies them to the site server.
  • MP_Status.log – Converts XML.svf status message files from clients and copies them to the site server.


Mobile Device Management Log Files

  • DmClientHealth.log – Records the GUIDs of all the mobile device clients that are communicating with the Device Management Point.
  • DmClientRegistration.log – Records registration requests from and responses to the mobile device client in Native mode.
  • DmpDatastore.log – Records all the site database connections and queries made by the Device Management Point.
  • DmpDiscovery.log – Records all the discovery data from the mobile device clients on the Device Management Point.
  • DmpFileCollection.log – Records mobile device file collection data from mobile device clients on the Device Management Point.
  • DmpHardware.log – Records hardware inventory data from mobile device clients on the Device Management Point.
  • DmpIsapi.log – Records mobile device communication data from device clients on the Device Management Point.
  • dmpMSI.log – Records the MSI data for Device Management Point setup.
  • DMPSetup.log – Records the mobile device management setup process.
  • DmpSoftware.log – Records mobile device software distribution data from mobile device clients on the Device Management Point.
  • DmpStatus.log – Records mobile device status messages data from mobile device clients on the Device Management Point.
  • FspIsapi.log – Records Fallback Status Point communication data from mobile device clients and client computers on the Fallback Status Point.


Mobile Device Client Log Files

  • DmCertEnroll.log – Records certificate enrollment data on mobile device clients.
  • DMCertResp.htm (in \temp) – Records HTML response from the certificate server when the mobile device Enroller program requests a client authentication certificate on mobile device clients.
  • DmClientSetup.log – Records client setup data on mobile device clients.
  • DmClientXfer.log – Records client transfer data for Windows Mobile Device Center and ActiveSync deployments.
  • DmCommonInstaller.log – Records client transfer file installation for setting up mobile device client transfer files on client computers.
  • DmInstaller.log – Records whether DMInstaller correctly calls DmClientSetup and whether DmClientSetup exits with success or failure on mobile device clients.
  • DmInvExtension.log – Records Inventory Extension file installation for setting up Inventory Extension files on client computers.
  • DmSvc.log – Records mobile device management service data on mobile device clients.


Operating System Deployment Log Files

  • CCMSetup.log – Provides information about client-based operating system actions.
  • CreateTSMedia.log – Provides information about task sequence media when it is created. This log is generated on the computer running the Configuration Manager 2007 administrator console.
  • DriverCatalog.log – Provides information about device drivers that have been imported into the driver catalog.
  • MP_ClientIDManager.log – Provides information about the Configuration Manager 2007 management point when it responds to Configuration Manager 2007 client ID requests from boot media or PXE. This log is generated on the Configuration Manager 2007 management point.
  • MP_DriverManager.log – Provides information about the Configuration Manager 2007 management point when it responds to a request from the Auto Apply Driver task sequence action. This log is generated on the Configuration Manager 2007 management point.
  • MP_Location.log – Provides information about the Configuration Manager 2007 management point when it responds to request state store or release state store requests from the state migration point. This log is generated on the Configuration Manager 2007 management point.
  • Pxecontrol.log – Provides information about the PXE Control Manager.
  • PXEMsi.log – Provides information about the PXE service point and is generated when the PXE service point site server has been created.
  • PXESetup.log – Provides information about the PXE service point and is generated when the PXE service point site server has been created.
  • Setupact.log Setupapi.log Setuperr.log Provide information about Windows Sysprep and setup logs.
  • SmpIsapi.log – Provides information about the state migration point Configuration Manager 2007 client request responses.
  • Smpmgr.log – Provides information about the results of state migration point health checks and configuration changes.
  • SmpMSI.log – Provides information about the state migration point and is generated when the state migration point site server has been created.
  • Smsprov.log – Provides information about the SMS provider.
  • Smspxe.log – Provides information about the Configuration Manager 2007 PXE service point.
  • SMSSMPSetup.log – Provides information about the state migration point and is generated when the state migration point site server has been created.
  • Smsts.log – General location for all operating system deployment and task sequence log events.
  • TaskSequenceProvider.log – Provides information about task sequences when they are imported, exported, or edited.
  • USMT Log loadstate.log – Provides information about the User State Migration Tool (USMT) regarding the restore of user state data.
  • USMT Log scanstate.log – Provides information about the USMT regarding the capture of user state data.


Network Access Protection Log Files

  • Ccmcca.log – Logs the processing of compliance evaluation based on Configuration Manager NAP policy processing and contains the processing of remediation for each software update required for compliance.
  • CIAgent.log – Tracks the process of remediation and compliance. However, the software updates log file, *Updateshandler.log – provides more informative details on installing the software updates required for compliance.
  • locationservices.log – Used by other Configuration Manager features (for example, information about the client’s assigned site) but also contains information specific to Network Access Protection when the client is in remediation. It records the names of the required remediation servers (management point, software update point, and distribution points that host content required for compliance), which are also sent in the client statement of health.
  • SDMAgent.log – Shared with the Configuration Manager feature desired configuration management and contains the tracking process of remediation and compliance. However, the software updates log file, Updateshandler.log, provides more informative details about installing the software updates required for compliance.
  • SMSSha.log – The main log file for the Configuration Manager Network Access Protection client and contains a merged statement of health information from the two Configuration Manager components: location services (LS) and the configuration compliance agent (CCA). This log file also contains information about the interactions between the Configuration Manager System Health Agent and the operating system NAP agent, and also between the Configuration Manager System Health Agent and both the configuration compliance agent and the location services. It provides information about whether the NAP agent successfully initialized, the statement of health data, and the statement of health response.


System Health Validator Point Log Files

  • Ccmperf.log -Contains information about the initialization of the System Health Validator point performance counters.
  • SmsSHV.log – The main log file for the System Health Validator point; logs the basic operations of the System Health Validator service, such as the initialization progress.
  • SmsSHVADCacheClient.log – Contains information about retrieving Configuration Manager health state references from Active Directory Domain Services.
  • SmsSHVCacheStore.log – Contains information about the cache store used to hold the Configuration Manager NAP health state references retrieved from Active Directory Domain Services, such as reading from the store and purging entries from the local cache store file. The cache store is not configurable.
  • SmsSHVRegistrySettings.log – Records any dynamic changes to the System Health Validator component configuration while the service is running.
  • SmsSHVQuarValidator.log – Records client statement of health information and processing operations. To obtain full information, change the registry key LogLevel from 1 to 0 in the following location:HKLM\SOFTWARE\Microsoft\SMSSHV\Logging\@GLOBAL


Desired Configuration Management Log Files

  • ciagent.log – Provides information about downloading, storing, and accessing assigned configuration baselines.
  • dcmagent.log – Provides high-level information about the evaluation of assigned configuration baselines and desired configuration management processes.
  • discovery.log – Provides detailed information about the Service Modeling Language (SML) processes.
  • sdmagent.log – Provides information about downloading, storing, and accessing configuration item content.
  • sdmdiscagent.log – Provides high-level information about the evaluation process for the objects and settings configured in the referenced configuration items.


Wake On LAN Log Files

  • Wolmgr.log – Contains information about wake-up procedures such as when to wake up advertisements or deployments that are configured for Wake On LAN.
  • WolCmgr.log – Contains information about which clients need to be sent wake-up packets, the number of wake-up packets sent, and the number of wake-up packets retried.


Software Updates Site Server Log Files

  • ciamgr.log – Provides information about the addition, deletion, and modification of software update configuration items.
  • distmgr.log – Provides information about the replication of software update deployment packages.
  • objreplmgr.log – Provides information about the replication of software updates notification files from a parent to child sites.
  • PatchDownloader.log – Provides information about the process for downloading software updates from the update source specified in the software updates metadata to the download destination on the site server.
  • replmgr.log – Provides information about the process for replicating files between sites.
  • smsdbmon.log – Provides information about when software update configuration items are inserted, updated, or deleted from the site server database and creates notification files for software updates components.
  • SUPSetup – Provides information about the software update point installation. When the software update point installation completes, Installation was successful is written to this log file.
  • WCM.log – Provides information about the software update point configuration and connecting to the Windows Server Update Services (WSUS) server for subscribed update categories, classifications, and languages.
  • WSUSCtrl.log – Provides information about the configuration, database connectivity, and health of the WSUS server for the site.
  • wsyncmgr.log -Provides information about the software updates synchronization process.


WSUS Server Log Files

  • Change.log – Provides information about the WSUS server database information that has changed.
  • SoftwareDistribution.log – Provides information about the software updates that are synchronized from the configured update source to the WSUS server database.


Software Updates Client Computer Log Files

  • CAS.log – Provides information about the process of downloading software updates to the local cache and cache management.
  • CIAgent.log – Provides information about processing configuration items, including software updates.
  • LocationServices.log – Provides information about the location of the WSUS server when a scan is initiated on the client.
  • PatchDownloader.log – Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.
  • PolicyAgent.log – Provides information about the process for downloading, compiling, and deleting policies on client computers.
  • PolicyEvaluator – Provides information about the process for evaluating policies on client computers, including policies from software updates.
  • RebootCoordinator.log – Provides information about the process for coordinating system restarts on client computers after software update installations.
  • ScanAgent.log – Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.
  • ScanWrapper – Provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients.
  • SdmAgent.log – Provides information about the process for verifying and decompressing packages that contain configuration item information for software updates.
  • ServiceWindowManager.log – Provides information about the process for evaluating configured maintenance windows.
  • smscliUI.log – Provides information about the Configuration Manager Control Panel user interactions, such as initiating a Software Updates Scan Cycle from the Configuration Manager Properties dialog box, opening the Program Download Monitor, and so on.
  • SmsWusHandler – Provides information about the scan process for the Inventory Tool for Microsoft Updates on SMS 2003 client computers.
  • StateMessage.log – Provides information about when software updates state messages are created and sent to the management point.
  • UpdatesDeployment.log – Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface.
  • UpdatesHandler.log – Provides information about software update compliance scanning and about the download and installation of software updates on the client.
  • UpdatesStore.log – Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle.
  • WUAHandler.log – Provides information about when the Windows Update Agent on the client searches for software updates.
  • WUSSyncXML.log – Provides information about the Inventory Tool for the Microsoft Updates synchronization process. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.


Windows Update Agent Log File

  • WindowsUpdate.log – Located in %WINDIR%. Provides information about when the Windows Update Agent connects to the WSUS server and retrieves the software updates for compliance assessment and whether there are updates to the agent components.

(Taken from: HELO Windows Blog- http://blogs.msdn.com/lxchen/archive/2009/04/03/a-list-of-sccm-log-files.aspx)

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]

Setting language and time zone settings in Exchange 2007

July 1st, 2009 Udi Leutashi No comments

By default when a new mailbox access the OWA after the first logon the following screen appears, and we should choose the language and time zone settings:

How can we remove this screen? It’s easy just set up the DefaultClientLanguage parameter in the OWA virtual directory, using the following cmdlet: 

Set-OwaVirtualDirectory -identity “Owa (Default Web Site)” -DefaultClientLanguagage <language code>

Now, all the first logon will be using the language that we choose in the language code, here are some language codes:

  • English (Canada) : 4105

  • Portuguese (Brazil): 1046

  • French(Canada): 3084

  • Hebrew(Israel): 1037

Note: When you change the language code, this value is not filled out in the user attribute, when you return the value to 0, all the users that haven’t chosen yet the value will receive the option to choose. To rollback the settings to the normal behavior(user get to choose), just set up the language code with the 0 value.

More useful commands:

  1. List the DefaultClientLanguage of determined server:
    Get-OwaVirtualDirectory | Sect Name,DefaultClientLanguage

  2. Run the following command to set the logon and error language setting:
    Set-OwaVirtualDirectory -identity “Owa (Default Web Site)” -LogonAndErrorLanguage <language code>

  3. Run the following command to set the client languages setting for an individual mailbox:
    Set-Mailbox -identity <mailbox identity> -languages <language code>

  4. Validating the Language value in the mailboxes
    Get-Mailbox | Select Name,Languages

(Taken from: Anderson Patricio Blog-http://msmvps.com/blogs/andersonpatricio/archive/2007/06/06/changing-the-language-of-the-owa-logon-page.aspx

And from Technet- http://technet.microsoft.com/en-us/library/aa997435.aspx)

VN:F [1.9.3_1094]
VN:F [1.9.3_1094]

.