By default Configuration Manager 2012 client stores deployed packages in %windir%ccmcache folder and default disk space for cache folder is 5120 MB.

All deployed packages and also software updates will be keep in these default folder unless you specify custom location with installation options.

Regarding TechNet article please note that:

• Do not encrypt cache folder. Configuration Manager cannot download content to an encrypted folder.
• For the required programs, client does not automatically retry to download the content. You must redeploy the package.
• For the required applications, client automatically retries to download the content when it next downloads its client policy.

One of the main concern about client cache is auto-empty mechanism. There are several scripts around the web that deletes client cache but be aware that client will not be notified so will try to use cached content if installation is not succeed yet.

If you configure the package properties with the option to persist content in the client cache, client does not automatically delete package content from cache.

Likewise you can specify following properties to configure caching options on clients:

• DISABLECACHEOPT – If set TRUE, disables the ability of end users to change the client cache folder settings using Configuration Manager in Control Panel.
• SMSCACHEDIR – Specifies the location of the client cache folder.
• SMSCACHESIZE – Specifies the size of client cache folder in megabyte.

Please note that if you use SMSCACHESIZE option and the package would cause the folder to exceed the maximum size, package download fails.

This article will discuss a high level overview about the migration from GroupWise to Exchange 2010.

The following steps summarize the migration process from GroupWise to Exchange 2010:

1. Design Exchange 2010.

2. Implement and configure Exchange 2010.

3. Select the migration software (3^rd party).

4. Setup Co-Existence between GroupWise and Exchange.

5. Migrate the users’ mailboxes.

In this article I will concentrate on Step 4. In my environment I will use Quest tools for the migration. Reading most of Quest guidance they covered the implementation of the tool and step 5 only, while the most important step (Step 4) is not covered.

Simply co-existence including mail flow is product configuration and not relevant to the migration software. In this article I will explain how to have mail flow between both systems and also will cover share SMTP namespace.

There are three options to for mail co-existence:

1. Single Namespace: in this scenario we will have one domain to cover both systems. As example tailspin.com domain will be used in both systems, each system will forward the emails to the other if there is no recipient locally as follows:

When users in GroupWise send email to one of Exchange users, GroupWise will not find a mailbox for the recipient locally and will forward the email to Exchange, same from Exchange side.

Problem: while this is easy to configure from Exchange side, I couldn’t find a way to do it from GroupWise side that will not result in loop. To avoid loops we must have one side responsible on sending NDR if it can’t find the user.

2. Different Domains: in this scenario we will have two different domains, one for each system:

a. groupwise.tailspin.com: for GroupWise users. Exchange users  will send to users in GroupWise using this address.

b. exchange.tailspin.com: users in GroupWise will send emails to Exchange users using this address.

3. Hybrid: to mix both approaches as follow:

a. Exchange Side: will use single namespace, Exchange will have mail contacts for all users in GroupWise, when mailbox in Exchange is sending to one of the GroupWise users (contacts in Exchange), Exchange will forward the email to GroupWise server. This will maintain GroupWise as the owner of the domain, which means if the user is not exist in GroupWise, GroupWise will issue Non Delivery Report (NDR).

b. GroupWise Side: for users planned to be  migrated from GroupWise to Exchange, Quest tool will configure forwarding rule that will forward all emails sent to user1@tailspin.com to user1@exchange.tailspin.com which reside on Exchange servers.

I’ve selected option 3 in my environment and the following steps explain the steps of how to configure in both environments:

 

Step 1: Configure Exchange with tailspin.com as shared namespace:

In Exchange we will need to configure the following:

1. Internal Relay Domain: the internal relay simply means that Exchange is not Authoritative (owner) of this domain, which means if the recipient email is not exist on Exchange it may be exist on another system (so no NDR will be generated).

The following article contains more information about the accepted domain: http://technet.microsoft.com/en-us/library/bb124423.aspx

The following snapshot shows how to configure Internal Relay Domain:

2. Create and configure Send Connector:

Create custom send connector with domain tailspin.com, make sure that the source server is the HUB servers (not Edge) and select “Route mail through Smart Host” this is should be the IP of the GroupWise server, if you will use CMG (Quest Co-existence Manage for GroupWise) then the IP should be the CMG’s IP.

3. Make sure that you have mail contact created for all users on GroupWise side, this is a mandatory step for the migration later, and can be done using Quest CMG (Co-existence Manage for GroupWise) Directory Connector or by import users to Active Directory using CSV file.

Step 2: Configure GroupWise Side:

When migrating a user from GroupWise to Exchange, one of the steps when using Quest tool “GroupWise Migration for Exchange” is to forward emails to Exchange account which should be user@exchange.tailspin.com.

So the steps to configure GroupWise as follow:

1. Configure Smart Host: this step will configure GroupWise to send all emails send to particular domain (exchange.tailspin.com) to a specific IP, again if you will use CMG then this is the IP of the CMG server.

This configuration should be done through route.cfg file on the GroupWise server, this file location is domain\qpgate\gwia, create the file if it’s not there.

Open the file in text editor and add the following line:

exchange.tailspin.com xxx.xxx.xxx.xxx

Where the IP is CMG IP or Exchange 2010 HUB. And restart the GWIA service (this is the service responsible of send/receive SMTP, similar to Exchange Transport Service)

2. Enable Flat Forwarding: in GroupWise the forward rule will send the email with from field from the user, example: user1 send email to user2, there is forward rule to forward all emails sent to user2@tailspin.com to user2@exchange.tailspin.com, all emails will go to Exchange side with from field from user2@tailspin.com (very strange to Exchange guys like me :)). To present from field as the real sender of the message we will need to enable flat forwarding.

The following steps show how to do it:

a. Open ConsoleOne > Browse to GWIA > open properties.

b. Select SMTP tab > check to enable flat forwarding. As the following snapshot:

3. When migrating the user’s mailbox using Quest GME (GroupWise Migration for Exchange) you will select GroupWise Administrative functions > select set forwarding from GroupWise to Exchange.

4. Step 3: Testing:

Send emails from Exchange to GroupWise and vice versa.

This article explained the main challenge which is co-existence, in the next articles we will discuss some of the migration problems that may happen during Step 5: The migration.

Configuration Manager 2012 provides bunch of built-in reports using SQL Reporting Services. In order to have these reports within ConfigMgr console you need a configured SQL Reporting Service. Then you need to install Reporting Services Point role for Configuration Manager 2012.

As I said, these reports are built-in reports. SQL queries, parameters and custom expressions are pre defined. You can get these information and edit or create your own reports easily. In this post I want to share one of my experience regarding a built-in report that did not meet with my requirement. I will try to show how I edited this report using Report Builder.

If you want to play with ConfigMgr reports, very first thing you need is Report Builder. To edit a built-in report, just navigate to reports folder, right click a report and choose edit.

But for the first time you may get following error message that indicates Report Builder is not installed:

With SQL Server 2008, Report Builder 2 is shipped. But if you are using SQL Server 2008 R2 as database server for ConfigMgr12 then you need to change following regedit key to point Report Builder 3 version which is default builder version for SQL Server 2008 R2.

• Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ConfigMgr10\AdminUI\Reporting\ReportBuilderApplicationManifestName
• Change value to ReportBuilder_3_0_0_0.application

After you successfully edit, navigate to reports node and click edit again.

I had a problem with the report “Hardware 10A-Computers in a specified collection that have changed during a specified timeframe” . I wanted to create an email subscription for the hardware changes. But this subscription must be daily and only must show data for yesterday. Thereby sccm admin will get report mail for hardware changes for only one day before.

But if you create a subscription using ConfigMgr console or Reporting Services Web site, SRS asks you for specific start and end dates. But I need to put a dynamic range which only includes previous day.

So I decided to use SRS web site to create a subscription as I can leave default for the start and end dates.

It worked great. There was no need to specify dates. But second problem was default values. As you see in above capture, by default report will be generated for whole month. Therefore I need to modify default range for this report.

I started Report Builder and checked for the parameters.

And find out that these reports have GlobalStartDate and GlobalEndDate parameters. Opened GlobalStartDate properties and checked for the default formula.

Here it is! This is why this report brings hardware change information for whole month. I just changed –30 to –1 and saved the report.

Now check default values again.

As you see range is only for one single day.

This is a simple modification. Using report builder you can create custom reports using custom expressions, parameters and Datasets. All you need to know is where your ConfigMgr asset data is stored.

 In this post I’m planning to walkthrough the practice of changing the SharePoint 2010 Search Service Database names as you might need it in the following scenarios:

• Replacing the Search Service Application Databases Names that Includes GUID’s to a friendlier name.
• The Database Admin in the Organization is planning to change the naming convention of all the Databases names in the Data Center.
• If you are planning to move from one Farm to another that has a different Naming Convention.

You have many options to do this practice as shown in the below figure, but in this post I will walkthrough the preferred steps only to make it simple and clear:

Renaming Property & Crawl DBs using Central Administration:

Verify that the user account that is performing the procedure is a member of the Farm Administrators SharePoint group.

1. In Central Administration, click Application Management.
2. On the Application Management page, click Manage service applications.
3. Click the name of the Search Service Application.
4. On the Search Administration page, click Modify.
5. On the Manage Search Topology page, the following three databases are listed: Administration, Crawl, and Property. You can point to renamed or moved Crawl or Property databases by using this procedure.
6. Click the database that you want to change, and then click Edit Properties.
7. In the Database Server text box, type the new server location if there is one; in the Database Name text box, type the new name for the database; and then click OK.
8. On the Manage Search Topology page, click Apply Topology Changes.

Notes:

• You cannot point to a renamed or moved Search Administration database by using Central Administration.
• It might take several minutes for the changes to take effect.

Renaming Search Service Application Database using PowerShell:

Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

1. On the Start menu, click All Programs.
2. Click Microsoft SharePoint 2010 Products.
3. Click SharePoint 2010 Management Shell.
4. At the Windows PowerShell command prompt, type the following commands:
• Point the Search Administration database to its new name or location.

$searchapp | Set-SPEnterpriseSearchServiceApplication -DatabaseName "<NewDbName>" -DatabaseServer "<NewServerName>" 

Where:

• <NewDbName> is the name of the renamed database
• <NewServerName> is the new database location
5. Monitor whether the search instances have finished re-provisioning.

Do {write-host -NoNewline .;Sleep 10; $searchInstance = Get-SPEnterpriseSearchServiceInstance -Local} while ($searchInstance.Status -ne "Online")

Additional References:

1. Rename FAST Search for SharePoint 2010 Databases
2. Rename or  Move Service Application
3. Change database (FAST Search Server 2010 for SharePoint)

The previous article explained the first challenge which is co-existence:

Challenges of Migration from GroupWise to Exchange 2010: Co-Existence

In this article I will talk about one of the most annoying problems that may affect the migration which is meeting request between Exchange and GroupWise.

Symptoms:

Meeting requests from GroupWise to Exchange working fine. However meeting requests from Exchange to GroupWise delivered as normal email without Accept/Deny buttons.

The following snapshot shows how GroupWise client receive the meeting request from Exchange:

As in the previous snapshot, meeting requests appear as normal email to the recipient.

Solution:

From Exchange Management Console (EMC), open the properties of the mail contact created for GroupWise recipient and for Use MAPI rich text format select “Never”, as the following snapshot

As expected GroupWise will never understand the MAPI format and will treat the meeting request as normal email.

This can be done for bulk users by simply execute the following cmdlet:

Get-MailContact |Set-MailContact -UseMapiRichTextFormat:never

After executing the cmdlet now the meeting request is a meeting request in GroupWise client: