Managing Internet Calendar Sharing in Exchange Server 2010 Service Pack 1

Managing Internet Calendar Sharing in Exchange Server 2010 Service Pack 1 (Part 1)

Managing Internet Calendar Sharing in Exchange Server 2010 Service Pack 1 (Part 1)

This article will cover one of the new features of Exchange Server 2010 which is the ability to Share and retrieve Calendar information with Internet Users.

Introduction

Exchange Server 2010 Service Pack 1 release brought a lot of new features to the table (by the way, this article is based on the Beta version available on the Internet) and in this article we will cover Internet Calendar Sharing with Internet users. Exchange Server 2010 RTM allows federated calendar between Exchange Server 2010 organizations (or at least an Exchange Server 2007 organization with an Exchange Server 2010 CAS just for Federation would work as well) where it increases the collaboration not just among users within the same organization but among different companies.

Now, Exchange Server 2010 SP1 goes beyond the company federation and allows end-users to share and retrieve calendars on the Internet in a secure and controlled way. There are two layers of security when we are talking about Calendar Sharing: the first layer is the organization level where the Exchange Administrator sets the boundaries for the Calendar Sharing; the second layer is at user level where the user can restrict a little bit more what was permitted at the Organization level. Users can easily go through OWA for instance and reduce the time window, the amount of information to be available, and their own calendar permissions. That is, either restricted or public available.

In order to provide Internet Calendar Sharing in Exchange Server 2010 Service Pack 1 and allow integration with common Internet calendars such as Live and Yahoo. Also, basing it on the iCalendar standards (RFC 2445), keep it secure and anonymous a new Virtual Directory was added to the current OWA structure, as shown in Figure 1. This new Virtual Directory has only Anonymous Authentication enabled and makes easier to an end-user to navigate in a Shared Calendar using the same Outlook Web App experience.

Figure 1

Managing Internet Calendar at Organization and CAS level

On the server side we have two different items to play with:

CAS Server and Organization configuration.

The first requirement is to enable and configure the external URL on your OWA Virtual Directory. In order to do that we can open Exchange Management Console, expand Microsoft Exchange On-Premises (<ServerName>), expand Server Configuration, and click on Client Access. Then, let’s select the desired Client Access server on the right panel, and double click on owa (Default Web Site) on the Outlook Web App tab.

In the General tab of the OWA properties, we can set the External URL by just typing in the information, as shown in Figure 2.

Figure 2

Note:
If for some reason you change your External URL you have to ask your users or at least create a script/cmdlet to stop and start publishing their calendar to get the new URLs.

The second phase of the Server level configuration will occur on the CAS Servers facing the internet where we must make sure that Internet Calendar Publishing is enabled. The attribute that we are looking for is the CalendarPublishingEnabled attribute, in order to have Internet Calendar functionality the value must be set to True. In order to retrieve the current value we can use several different ways, here we can see a couple of possible options:

• To list the Calendar of all CAS Servers:
  Get-OWAVirtualDirectory | Select Name, Server, Calendar*
  
• To list the information from a specific server (Figure 3)
  Get-OWAVirtualDirectory –Server <ServerName> | Select Name, Server, Calendar*

Figure 3
Now that we know how to list and validate if the server is correctly configured for Internet Calendar Sharing, we may have to enable the feature using the following options:

• To change all servers:
  Get-OWAVirtualDirectory | Set-OWAVirtualDirectory –CalendarPublishingEnabled:$true
  
• To change a specific server specifying the server on the Set-OWAVirtualDirectory cmdlet
  Set-OwaVirtualDirectory -Identity "<ServerName>\owa (Default Web Site)" -CalendarPublishingEnabled:$true
  
• To change a specific server without specifying the ServerName\VirtualDirectory we could use the first cmdlet specifying the server in the first cmdlet to facilitate the process:
  Get-OwaVirtualDirectory -Server <ServerName> | Set-OwaVirtualDirectory -CalendarPublishingEnabled:$true

The last step is to configure a Sharing Policy to allow Internet Sharing Calendar and define the level of information will be available to the end-users. The most important thing is that the domain must be set to Anonymous and any of these values for security are valid: Calendar Sharing with free/busy information only, Calendar sharing with free/busy information, plus subject and location, or Calendar sharing with free/busy information, plus subject and location and body.
We will be examining some examples of these three levels in a little bit.
The above explanation is shown in Figure 4, it does not matter if we are changing an existent policy or creating a new one from scratch but essentially the information entered will be similar to Figure 4.

Figure 4

Enabling Internet Calendar to all users

Now that we know how to configure the Sharing Policy in order to have Internet Calendar going, it’s time to demonstrate how to enable it to all users of your organization. The first step is to change the Default Sharing Policy. From the Exchange Management Console, follow these steps:

1. Open Exchange Management Console
   
2. Expand Microsoft Exchange On-Premises (<ServerName>)
   
3. Expand Organization Configuration
   
4. Click on Mailbox
   
5. Click on Sharing Policies tab
   
6. Double click on Default Sharing Policy
   
7. Select the existent Domain listed and click on Edit. Change the Domain to Anonymous and Action based on your requirements. Also make sure that Enable Sharing Policy setting is enabled, as shown in Figure 5.

Figure 5

8. Click on OK. You may receive a warning dialog box saying “Warning: You’re allowing users to access the feature that lets them publish their calendars. Make sure that the Calendar virtual directory has been enabled on the Client Access Servers so that published calendars will be accessible”, click OK.

It will work for all users that do not have any other Sharing Policy associated with their mailbox. By default all users are associated to the Default Sharing Policy, as shown in Figure 6.


Figure 6

Enabling Internet Calendar Sharing using a different policy

Another way to deploy Internet Calendar Sharing is creating a new Sharing Policy and then associating the new policy with a specific set of users. These are the steps that can be performed to achieve this solution:

1. Open Exchange Management Console
   
2. Expand Microsoft Exchange On-Premises (<ServerName>)
   
3. Expand Organization Configuration
   
4. Click on Mailbox
   
5. Click on Sharing Policies tab
   
6. Click on New Sharing Policy…
   
7. In the Introduction page. Type in the new policy name, and define the permissions and domain (Anonymous for Internet Calendar) as we’ve just seen in the previous section (Figure 7) and click Next.

Figure 7

8. In the Mailboxes page (Figure 8). Select mailboxes that will be set with this new policy. Let’s associate just a single user to start testing and then click Next.

Figure 8

9. In the New Sharing Policy page. A summary of all configuration that we have defined so far will be displayed, just click New.
   
10. In the Completion page. We will see the cmdlet used to create the new Sharing Policy and also a cmdlet for each user defined in the previous steps to receive the new Sharing Policy.

Managing Internet Calendar Sharing in Exchange Server 2010 Service Pack 1 (Part 2)

   

.

Intorduction

In the first article we covered all steps to enable Internet Calendar Sharing on the server side, now it’s time to see how the end-users can manage their Calendar information using the new features added to the Exchange Server 2010 Service Pack 1.
Let’s say that we have just added the user to the Sharing Policy and now the user can open its Outlook Web App session and click on Calendar, and then click on Share menu, as shown in Figure 01. The user will have two new useful items: Publish This Calendar to Internet and Change Publishing Setttings (are available only after enabling the feature on the user). Let’s click on Publish This Calendar to Internet…

Figure 01
In the new window called Calendar Publishing – Calendar we can define a couple of settings to publish the Calendar, as follows:

• Publishing Detail
  We can define three different levels: Availability Only, Limited Details (which will show Appointment Subject, Date and time and also location), and Full details (which adds everything that we have in the Limited Details plus description of the appointment).
  Note:
  Bear in mind that Sharing Policy settings drive the level of Publishing Detail that the end-user can set on his own calendar. If the policy is availability only, that will be the maximum that the end-user will be able to use because Sharing Policy sets the boundaries to the end users.
  
• Publish my calendar
  User can define how many months/weeks/days before and after Today that will be published. The standard is 3 months.
  
• Access Level
  It will define if the URL created by the wizard will be easily searchable (Public) or hard to guess (Restricted).

After choosing the options we can click on Start Publishing (Figure 02).

Figure 02
The results can be seen in the Figure 03, the only difference is that now we have two URLs one link to subscribe to the calendar (a link to the calendar.ics file that can be consumed by any Calendar application) and the second one is to the Calendar virtual directory created during Service Pack 1 installation/upgrade process. The user can also click on Copy links to the Clipboard... to have both addresses in memory. We can stop anytime the Internet Calendar Sharing by just clicking on Stop Publishing.

Figure 03
If the mailbox user sends the link to an external user, the external user will be able to see the calendar using the link to view the calendar in a really nice way (Figure 04). Let’s analyze the Calendar view: first of all it is totally anonymous, it is also HTTP not HTTPS, there is no way to access user mailbox data or whatsoever, it’s just calendar information based on the configuration defined in the previous step.
Let’s also analyze what an Anonymous user that has the link can use of this new feature:

• Remote user has access to the calendar using Outlook Web App experience
  
• On the upper left side the name of the user will be displayed, besides of the URL informing the user name the remote user can double check there
  
• On the upper right side all time range is available to the user, in the figure below the remote user won’t see any data before 11-May-2010 or after 12-November-2010
  
• Remote user can change the time zone clicking on Time Zone section and it will change the appointments view to the desired Time Zone on the fly
  
• Remote user can choose daily, weekly and monthly views of the calendar
  
• Users can click on Subscribe and a file called calendar.ics will be available to download to use in your favorite software.
  
• Remote users have the ability to print the calendar (day, week or month) just a couple of clicks away

Figure 04
If the mailbox user goes back to the Change Publish Settings… and change settings such as reduce the time range to be available or even configure the Publishing detail to Full Details all these changes will be available on the Internet view of the Shared Calendar.
If the user uses Restricted Access level a tough guess URL will be created and the user will be responsible to share the URL with his personal contacts, but if for some reason he doesn’t want to share with a specific Internet user, then the user has to stop publishing and start publishing again to recreate a new URL and then inform its contacts about the new URL.

Sharing a calendar afterwards…

The user can go back any time to the Publishing Calendar settings, clicking on Share and then Change Publishing Settings, but if the user just wants to invite a new Internet user to his calendar, he can just click on Share and then click on Send links to this calendar… as shown in figure 05.

Figure 05
The new window will be a new message that contains an invitation containing the links to view and subscribe to the user calendar (Figure 06).

Figure 06

Using Exchange Server 2010 and Windows Live Calendars…

In this section we will check both sides of the Internet Calendar sharing the subscription on Exchange side and also how an Internet Calendar service can take advantage of the published calendar on Exchange.
First, let’s start with the subscription where I’m going to use my Live Calendar (calendar.live.com) and the initial page is shown in Figure 07, and I’ve just added a couple of appointments on the calendar just to give more authenticity to our test.

Figure 07
A Live Calendar user can click on Share, and a new page will allow us to protect the calendar, just for test purposes I’m going to configure the calendar as public (I will check the option Make your calendar public) and then a link for HTML view and ICS will be available. I will be clicking on Import into another calendar application link, and the URL will be displayed in a new page, as shown in Figure 08. By the way, Live Calendar has almost the same experience of Exchange Server which makes even easier to work on both tools.

Figure 08
Let’s go back to Exchange side, opening Outlook Web App, and let’s click on Calendar item, then Share menu, and finally on Add Calendar… Let’s select Calendar from the Internet and paste the URL that we got from the previous Live Calendar page. (Figure 09)

Figure 09
The results of the operation will be a calendar with a globe icon on the left side and if it is selected the information will be displayed on the right hand side, as shown in Figure 10.

Figure 10
On the flip side, users using Windows Live Calendar can subscribe to a Calendar Published on Exchange Server 2010 just clicking on Subscribe and then they can specify the URL that was provided in the Outlook Web App, as shown in Figure 11.

Figure 11

Import your messages or account from Outlook Express to Outlook

Show All

Applies to
Microsoft Office Outlook® 2003 Microsoft Outlook® 2002

Microsoft Outlook® Express is a no-cost, basic e-mail program that is included with Microsoft Internet Explorer. You can import e-mail messages from Outlook Express into Outlook. The process you use depends on whether the two e-mail programs are installed on the same computer.

In Outlook Express, each folder corresponds to a group of stored messages; for example, the Outlook Express Inbox folder is a single file, Inbox.dbx. Conversely, Outlook stores each message as an individual file. If Outlook Express and Outlook are installed on different computers, you need to know this information so that you can find and copy the correct folder when needed.
To import e-mail messages, choose a procedure based on whether Outlook Express and Outlook are installed on the same or different computers.

Import messages from Outlook Express

When Outlook and Outlook Express are installed on the same computer

1. In Outlook, on the File menu, click Import and Export.
2. Click Import Internet Mail and Addresses, and then click Next.
3. Click Outlook Express.
4. Select the Import mail check box.
5. Click Next.
6. Click Finish.
7. To save a copy of the import summary to your Inbox, click Save in Inbox.

When Outlook and Outlook Express are installed on different computers

To transfer messages by using the Import and Export Wizard, you must first locate and copy the correct files from the computer where Outlook Express is installed to the computer where Outlook is installed.
Note Copying the Outlook Express information to a shared location won't work. You must copy the folder to the same computer where Outlook is installed.

Copy Outlook Express folder

1. On the computer where your Outlook Express account is set up, in Outlook Express, on the Tools menu, click Options.
2. Click the Maintenance tab.
3. Click Store Folder, and then note the entire path shown in the field in the Store Location dialog box.

Tip Record this location so that you can recall it later in this procedure. You can do this quickly by selecting the information in the field, pressing CTRL+C to copy, and then opening Microsoft Notepad and pressing CTRL+V to paste it there.

4. If necessary, modify the default view in Windows Explorer so that you can see hidden folders. The Outlook Express folder is located in a hidden folder.

How?

Microsoft Windows® XP or Microsoft Windows Server™ 2003

1. Click Start, and then click My Computer.
2. On the Tools menu, click Folder Options.
3. Click the View tab, and then click the Show hidden files and folders option.

Microsoft Windows® 2000

1. Double-click My Computer on your desktop.

Note If My Computer is not on your desktop, click Start, point to Programs, point to Accessories, and then click Windows Explorer.

2. On the Tools menu, click Folder Options.
3. Click the View tab, and then click the Show hidden files and folders option.

5. Browse to the location that you found in the Store Location dialog box.

• Do one of the following: Copy the entire Outlook Express folder to removable media, such as a floppy disk, DVD, or portable memory device, and then copy it to the computer where Outlook is installed.

Note When you transfer this information to the computer with Outlook, the destination is not critical, because the information will only be stored there temporarily. Copy it to a place that you can easily remember and find.

• Copy the entire Outlook Express folder to a network location that the computer with both Outlook and Outlook Express has access to.

6. On the computer where Outlook is installed, open Outlook Express. If prompted to create an e-mail account, click Cancel.
7. On the Tools menu, click Options.
8. Click the Maintenance tab.
9. Click Store Folder and then click Change.
10. Browse to the location where you copied the Outlook Express folder, and then click the folder that you copied in step 6. Click OK.
11. To close the Store Location dialog box, click OK.
12. When prompted to use the new messages or replace them with messages from the old store location, click Yes to switch to that store.
13. Close Outlook Express, and then open it again to complete the process.

Import Outlook Express messages into Outlook

1. In Outlook, on the File menu, click Import and Export.
2. Click Import Internet Mail and Addresses, and then click Next.
3. Click Outlook Express.
4. Select the Import mail check box.
5. Click Next.
6. Click Finish.
7. To save a copy of the import summary to your Inbox, click Save in Inbox.

Import account information

Import account name and server settings from Outlook Express

1. In Outlook, on the File menu, click Import and Export.
2. Click Import Internet Mail Account Settings, and then click Next.
3. Click Outlook Express, and then click Next.
4. Follow the remaining instructions in the Import and Export Wizard.

from :
http://office.microsoft.com/en-gb/outlook-help/import-your-messages-or-account-from-outlook-express-to-outlook-HA001094387.aspx

Kaspersky WindowsUnlocker to fight ransom malware

Home / Fighting malicious programs / Viruses and solutions

 
 

 
 

Kaspersky WindowsUnlocker to fight ransom malware

This section explains how to neutralize complicated malware, i.e. when user participation is required to modify the system registry or execute a special utility, for example. If you have not found the requested information in this section please submit a request to the Kaspersky Lab Technical support.

 
 

 
 

Kaspersky WindowsUnlocker to fight ransom malware
ID Article: 8005

If when working with the computer a banner (ad's module) appears on the screen and requests sending sms to a specified phone number, it means that your computer is infected with ransom malware. Such malware are created to block access to a computer or restrict access to some functions and request a ransom to restore computer functionality.

In order to fight ransom malware Kaspersky Lab specialists designed a special utility Kaspersky WindowsUnlocker. The utility can be launched when your computer is started from Kaspersky Rescue Disk 10 and allows working in graphic and text modes of Kaspersky Rescue Disk.

In the article you can find detailed description on how to work with the Kaspersky WindowsUnlocker utility:

1. Functions of Kaspersky WindowsUnlocker
   
2. How to start computer from disk with the utility
   
3. How to launch Kaspersky WindowsUnlocker and disinfect computer
   
4. How to scan computer using Kaspersky Rescue Disk
   
5. Reports of Kaspersky Windows Unlocker
   
6. If Kaspersky WindowsUnlocker won't help
   

1. Functions of Kaspersky WindowsUnlocker

The Kaspersky WindowsUnlocker utility is designed to disinfect registries of all operating systems installed on the computer (including operating systems installed on different partitions or in different folders on one partition) and disinfect user registry trees. Kaspersky WindowsUnlocker does not perform any actions with files (in order to disinfect files you can use Kaspersky Rescue Disk).

Top of page

2. How to start computer from disk with Kaspersky WindowsUnlocker

Kaspersky Rescue Disk recording to CD/DVD or USB removable device should be performed on not infected computer connected to the Internet.

 
 

1. Download the disk with Kaspersky WindowsUnlocker

Download kav_rescue_10.iso (~236 MB) from the Kaspersky Lab server.

2. Record the image to a CD/DVD or removable device

2.1 How to record the image to a CD/DVD

You can record the iso image to a CD/DVD using any record program (for example, Nero Burning ROM, ISO Recorder, DeepBurner, Roxio Creator etc.).

 
 

2.2 How to record the image to a removable USB device

In order to record the image to a removable USB device, perform the following actions:

1. Connect your removable USB device to the computer.
   

In order to successfully record the image to a removable USB device, space capacity of it must be not less than 256 MB. The connected USB device must have FAT16 or FAT32 file system. If NTFS file system is installed on the device, you are required to format it in FAT16 or FAT32. Do not use an USB device with other operating systems installed on it. It may cause incorrect booting your computer.

1. Download the utility to record the image to USB devices from the Kaspersky Lab server (~378 KB).
   
2. Run the downloaded file rescue2usb.exe.
   
3. On the Kaspersky USB Rescue Disk Maker window, click Browse... and select the iso image of Kaspersky Rescue Disk
   

1. Select the required USB device from the drop-down menu.
   
2. Click START.
   
3. Wait until the process is complete.
   

1. Click OK on the open window informing that Kaspersky USB Rescue Disk has been successfully created.
   

3. Configure the computer

In order to boot the BIOS menu, use the keys Delete or F2. The keys F1, F10, F11, F12, as well as the following combinations may be used for some motherboards:

• Ctrl+Esc
  
• Ctrl+Ins 
  
  
• Ctrl+Alt 
  
• Ctrl+Alt+Esc
  
• Ctrl+Alt+Enter
  
• Ctrl+Alt+Del
  
• Ctrl+Alt+Ins
  
• Ctrl+Alt+S
  

Information how to open the BIOS menu is displayed at the start of the OS boot:

• Enable booting from CD/DVD ROM or a removable device in BIOS settings (for more details refer to the documentation for the motherboard installed on your computer):
  
  • If you recorded the image to a CD/DVD, select CD-ROM Drive
    
  • If you recorded the image to a removable USB device, select Removable Devices
    

1. Insert the disk into the CD/DVD ROM drive or connect the removable USB device.
   

4. Boot your computer from Kaspersky Rescue Disk 10

1. Restart your computer. After reboot, a message will appear on the screen: Press any key to enter the menu.
   

1. Press any key. A loading wizard will start (you will see the menu to select the required language).
   

If you do not press any key in 10 seconds, the computer boots from hard drive automatically.

 
 

1. In the start up wizard window that opens, select the graphic interface language using the cursor moving keys. Click the ENTER key on the keyboard.
   

• Select one of the following start up methods:
  
  • Kaspersky Rescue Disk. Graphic Mode loads the graphic subsystem.
    
  • Kaspersky Rescue Disk. Text Mode loads the text user interface represented by the Midnight Commander (MC) console file manager.
    

1. Press the ENTER key on the keyboard.
   

1. The End User License Agreement of Kaspersky Rescue Disk 10 will be displayed on the screen. Read carefully the agreement. If you agree with all the statements of the agreement press the 1 to accept the agreement, press 2 to reboot and 3 to shut down the computer.
   

Once you performed the actions described above, the Linux operating system is started. It scans connected devices and detects operating systems installed on the computer. Once the operating system is booted, you can start working with it.

If the host operating system is in sleep mode or its operation has been completed incorrectly, you will be informed about it.

In order to shut down the operating system correctly, select Restart computer.

If you select Continue
Kaspersky Rescue Disk will continue mounting the file system, but there is a fairly high risk of file system damage.

 
 

If you select Skip Kaspersky Rescue Disk will skip file system mounting. Only boot sectors and autorun elements will be scanned. In this case the file system can also be damaged.

Top of page

3. How to launch Kaspersky WindowsUnlocker and disinfect the registry

In order to disinfect the registry using Kaspersky WindowsUnlocker, perform the following actions:

• If you booted Kaspersky Rescue Disk in the graphic mode, click the button К ; in the bottom right corner of the screen and in the menu select Terminal. In the command prompt enter the command windowsunlocker and press Enter on the keyboard.
  

 
 

• If you booted Kaspersky Rescue Disk in the text mode, press F10 to close the menu. At the bottom of Midnight Commander in the command prompt enter windowsunlocker and press Enter on the keyboard.
  

 
 

After the utility start the menu with the commands will appear in the Terminal window (to select a command, press the corresponding key and then press Enter on the keyboard):

 
 

• 1 – Unblock Windows (the utility will clean the registry and will display results in the window).
  

Kaspersky Lab experts strongly recommend performing this action.

 
 

• 2 – Save boot sector copies (the utility will copy boot sectors into the Quarantine folder. The path to the created files (/var/kl/WUnlocker.1.2.0.0_%dd.mm.yy_hh.mm.ss_quarantine/ will be displayed on the screen).
  

• 0 - Exit.
  

Top of page

4. How to scan computer using Kaspersky Rescue Disk

Having cleared the registry, you need to remove the remains of the ransom-blocker from your computer. For this, run full computer scan using Kaspersky Rescue Disk.

Top of page

5. Reports of Kaspersky WindowsUnlocker

The report (log file) of the utility can be requested by Kaspersky Lab specialists to analyze your request to Kaspersky Lab Technical Support. You can create a request via the My Kaspersky Account service. In order to view the utility report, perform the following actions:

1. On the desktop double-click File Manager to open it (if you work in the text mode, close User Menu, by pressing F10).
   

1. In the File Manager menu (in the text mode - Midnight Commander) find the folder /var/kl  (or /var/tmp in case the first folder is not accessable) and open it.
   
2. The folder containing the text file with the name WUnlocker.1.0.1.0_%dd.mm.yy_hh.mm.ss_log%.txt will open. The file contains reports on Kaspersky WindowsUnlocker work.
   

When you finish work with the Kaspersky WindowsUnlocker utility, restart your computer and in the Boot menu of BIOS parameters select your hard drive.

Top of page

6. If Kaspersky WindowsUnlocker won't help

If you have any questions concerning the usage of the utility or cannot perform any steps from the instruction, visit Kaspersky Lab official forum.

Top of page

Inserted from <http://support.kaspersky.com/faq?chapter=176492791&print=true&qid=208285998>

SBS server Migration

SBS Server Migration by Riddhim Dhawan a few tips, tricks and tweaks

SBS2003 to SBS2008 or SBS2011 Migration: Active Directory replication is taking longer than expected.

Scenario: You are doing a migration from SBS 2003 to SBS 2008 or SBS 2011. You’ve created your answer file, you’ve gotten partway through setup, but it seems to sit forever at this screen:


Eventually, you get this pop-up dialog telling you at it is taking longer than expected, and asking if you want to keep waiting.

What now? Maybe you’ve clicked the yes button once or twice already and waited another 20 minutes with no positive results.
Well, this is what happened to me, and I’ll tell you what I found out about it. Your situation may be different, but check out what I found out, and look for it in yours. If it matches, you might want to give it a try. Hopefully you have a good backup.
After sitting at this screen for way too long, I decided to do some digging. I sent a ctrl-alt-del to the SBS 2008 server and brought up the Task Manager. From there, I opened a CMD prompt, and found my way to C:\Program Files\Windows Small Business Server\Logs. I copied the file to a UNC share on the source SBS server to read it (but you can just use the “type” command in the CMD window and read the last few lines if you want).
The last few lines looked like this:

[3212] 081225.202335.1592:
Task: There are 0 pending replication operations.
[3212] 081225.202335.2530:
Setup: Attempting LDAP bind.
[3212] 081225.202335.2530:
Setup: Bind failed with: A local error occurred.
[3212] 081225.202335.2530:
Task: Waiting for replication to finish

That sequence repeated a few times. Definitely the choking point. I googled the hell out of that, and only found one item that looked remotely relevant. That guy was having the same symptom. He solved his problem by throwing away his SBS2003 domain and starting from scratch.
After MUCH digging, rebooting, retrying, and other things that I will spare you the pain of, I typed “eventvwr” at the CMD prompt, and looked through the event logs. I found, among other things, this event:
Source; GroupPolicy
Event ID: 1006
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller (LDAP Bind function call failed).
Now we’re getting somewhere. I found numerous search results for that one, including a forum where some guys had this error, received a hotfix from Microsoft, and the problem went away. Apparently the problem is caused if you have ever done an authoritative restore on your 2003 domain. When that happens, the msDS-KeyVersionNumber property from the user object “krbtgt” is increased. Windows Server 2008 is not expecting this. Any 2008 DCs that are added to this domain have trouble binding to LDAP and authenticating to AD because of this.
There is a Microsoft KB article about a seemingly completely unrelated topic, with a hotfix link available for download. Microsoft PSS sent these guys this hotfix, and it made that problem go away. It needs to be installed on all Windows 2003 DCs.
Note: One of the commenters posted that if the hotfix is no longer available at Microsoft, it can be found here.
I am doing this upgrade on a virtual server, I have a snapshot, so I figured “What the heck, let’s try it!” and downloaded the hotfix. I ran it on my SBS 2003 server, and said No to the reboot. Lo and Behold, my SBS 2008 migration is proceeding past the error point! It’s looking good!
Use this fix with caution. Your mileage may vary. Make sure you have backups and/or a snapshot before you do it. Best of luck!
Update: Many thanks to all of the commenters. With the comments, this is now a fairly comprehensive SBS migration troubleshooting guide for migrations from SBS 2033 to SBS 2008 or SBS 2011.








I had exactly similar issues. The logs looked the same. You will notice that when you check the operation masters on 2003 SBS server they will show and ERROR on operation master and in AD sites and services the replication link will be missing on the 2008 server.
Out of frustration I rebooted the 2008 server during the setup and hell crashed on me. The source server was in the middle of migration and schema had been changed to a no comming back stage. I did a restore on the source server once when it crashed and started setup again with image on the source server.
I tried to do the install manaully without the answerfile but the same issue. The server is happy until I promote it to a Domain Controller. Then I get the following error message regarding Group Policy:
“The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.”
I started the setup again and got stuck at excatly the same spot. I pressed ctrl+alt+del on 2008 and started eventvwr from task manager. It showed the following errors.
Source; GroupPolicy
Event ID: 1006
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller (LDAP Bind function call failed).
I then installed the hotfix from MS as mentioned in the article and everything was fine.
Thanks guys.
This is what I have learnt.
1. Check clocks are in sync.
2. Check FRS, DNS and DHCP on Source Server ( Some idiot had DNS set it to manual on my server).
3. I was prompted for 2003 SP1 not installed where as I had SP2 on it. ( I added the reg key manually on the 2003 ! Setup is dumb.
HKLM\SOFTWARE\Microsoft\SmallBusinessServer\ServicePackNumber ( = 1) )
4. Check Sysvol permissions.
5. Install the hotfix FIX 226580
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=939820&kbln=en-us
6. Always take an image backup of source before you start anything. There are things that can go terribly wrong as they went worng with me.

 

ANOTHER MIGRATION ANOTHER ERROR

 

In addition to following I had set DNS for both servers to IP address of new server!
I have just copied the following from a website: ( Credits to them)
Replication Issues.
AD replication is taking longer than normal, do you want to wait for replication
This one happens sometimes. You will install, the AnswerFile gets picked up, and after a few reboots you get a message stating that the AD replication is taking longer than normal, do you want to wait for replication? You have two problems now. First, the Source isn’t replicating properly and you need to fix that problem, and secondly, many times the Destination server has stopped trying to replicate because of the failure.
Source server:
Check that these services are running, this is the most common cause of failure to replicate:
Computer Browser
File Replication Service
Remote Procedure Call (RPC) (and I always start the Locator too, don’t know if it helps but I do)
Server
Workstation
Disable Firewall! If you don’t make a habit of doing so already, the Firewall can really muck up a migration. You probably have a better firewall in your AV program already anyway.
So now you have the problem figured out, let’s get the two to start talking again. There is one registry key on the Source, and two on the Destination which need to be fixed.
Source:
HK_LM\System\CurrentControlSet\Services\NTFrs\Parameters\Backup/Restore\Process at Startup
Change the BurFlags key to D4 on the old server
Dest:
Obviously there is no run, so you need to bring up either Task Manager or a command prompt. I know there is another hotkey for CMD but I don’t remember what it is most of the time, so I just use CTRL+SHIFT+ESC, which brings up Task Manager. File>New Task will get you a run so you can open up the registry. Now change the same BurFlags key to D2 on the new server
Also go find the key HK_LM\System\CurrentControlSet\Services\Netlogon\Parameters and make sure the SysvolReady key says 1, if not change it.
Now stop the NTFrs service on both servers, and start the Source first, then the Destination, and on the Destination server click Yes to wait for the AD replication. If it worked, you should see almost immediate results.


All the best people

Riddhim

Replacing the Exchange 2007 Self-Signed Certificate

ExchangeInbox.com - Replacing the Exchange 2007 Self-Signed Certificate (Part 1)

 

Active Directory stores various Exchange configuration settings. If we need a list of email addresses, domain controllers, or legacy DNs for ExMerge, the Active Directory export tools will do the job.

Active Directory hosts objects that together define the core elements of a Windows network. Computer and User objects are two examples of the many object types residing here.
Exchange was one of the first to embrace the extensibility opportunities AD provided. From Exchange 2000, AD absorbed the Exchange configuration objects and user mailbox information. The directory brought together the information for Windows users and Exchange mailboxes. Since then, AD continued to play this important role in all subsequent releases including the latest Exchange 2007.
Today we look at some tools allowing us to extract information from Active Directory. Microsoft provides a good number of these. The ones we will discuss, LDIFde.exe and CSVde.exe, are installed with Windows 200x Server.
Our discussion will mainly focus on the export of user objects. However the same could be applied to any other AD object.

What is a User?

In Active Directory terminology a user is an object of class "user". To an Exchange administrator this definition may need to be broadened to include all objects that are listed at the address book. However to begin with let's have a look at how a user looks like when exported using the LDIFde.exe command:
ldifde -f c:\temp\user1.txt -d cn=user1,cn=users,dc=vertical,dc=local -v
In this case I am extracting a user named "user1" and saving it to an external file. Looking at the exported data we see how a user object, like any other AD object, boils down to a bunch of properties. Here is how the exported data looks like:

The following are some user object properties of interest to Exchange administrators.
dn: CN=user1,CN=Users,DC=vertical,DC=local
The Distinguished Name DN identifies exactly where the object is located within the directory. This is similar to a reversed directory path. The path starts from the object name, and traverses the directory upwards to the root.
cn: user1
The Common Name CN is the object name, the first part in the object DN.
proxyAddresses: SMTP:user1@vertical.local
proxyAddresses: X400:c=US;a= ;p=First Organizati;o=Exchange;s=user1;
proxyAddresses are the set of user addresses. These are generated and maintained by the Exchange Recipient Update Service RUS. Typically here we find SMTP and X400 addresses. However other address types may also be present, such as those used in FAX server gateways.
mailNickname: user1
The mailNickname is the SMTP email alias. In Exchange this is often used to identify objects that are to appear in an Address book.
legacyExchangeDN:
/o=First Organization/ou=First Administrative Group/cn=Recipients/cn=user1
The legacyExchangeDN is another type of distinguished name. This used to be the DN format in Exchange 5.5 and earlier versions. Today we still encounter these especially when dealing with MAPI applications such as ExMerge.

Using LDIFde.exe and CSVde.exe

LDIFde and CSVde are two very similar command-line applications. Both allow us to import and export information to/from Active Directory. Furthermore the two applications support almost the same set of input parameters. As an example here is how to export a user with each of these tools:
ldifde -f c:\temp\user1.txt -d cn=user1,cn=users,dc=vertical,dc=local -v
csvde -f c:\temp\user1.txt -d cn=user1,cn=users,dc=vertical,dc=local -v
Don't waste too much energy looking for differences. It's the same set of parameters. This is great since learning how to use one application takes us a long way in using the other.
The main difference between the two is the file format used for importing/exporting data. LDIFde.exe uses the Lightweight Data Interchange Format. CSVde.exe uses the more familiar Comma Separated Value format.
When it comes to advanced directory operations, LDIFde.exe is the most appropriate. However here we won't really need this extra power. On the other hand CSVde.exe gives us a file format that can be easily opened in MS Excel or MS Access. This is very handy when going through a large number of objects.

Command Line Parameters

To get to the application help screen run the command without any parameters. Here is how the CSVde.exe help looks like (the one for LDIFde.exe is very similar).

Going through all the parameters is beyond the scope. Instead we will discuss the most important ones. Both applications run in export mode by default. As a minimum we typically need to add the -f and -d parameters. -f identifies the file where the exported data is to be saved. -d identifies the DN of the directory location from where the export is to start. This can be the DN of a specific object as we did in case of user1 above, or it could be the DN for a container holding other objects and containers.
Getting used to constructing DNs is our first step. Unfortunately the seemingly cryptic format tends to discourage some. However, when dealing with user objects this is quite easy. Just open the AD Users and Computers MMC console from which we can deduce the DN for any container/object:

In general we need to remember that when converting the domain FQDN (vertical.local) to an AD DN we need to use the 'DC=' (DC=vertical,DC=local). When dealing with organizational units we use 'OU=' and when dealing with other containers and objects we use 'CN='. Building the final DN starts from the container/object of interest and moves upwards towards the root. So the DN for the user Alex under the Malta organizational unit is just a matter of bringing together all the parts:
CN=alex,OU=Malta,DC=vertical,DC=local
Alternatively we could use another tool from Microsoft, ADSIEdit. Get the Windows 200x Server CD and install the support tools. Next browse to the 'Support Tools' directory under Program Files and run ADSIEdit.msc. See how the ADSIEdit tree view shows the exact name composing the DN.

We already learned enough to start exporting AD objects. Just remember to enclose any DNs containing whitespace in double quotes. The following shows how we can export all three users under the Malta OU:
ldifde -f c:\temp\Malta.txt -d ou=malta,dc=vertical,dc=local -v
csvde -f c:\temp\Malta.txt -d ou=malta,dc=vertical,dc=local -v
This will export all domain controller objects:
ldifde -f c:\temp\DCs.txt -d "ou=domain controllers,dc=vertical,dc=local" -v
csvde -f c:\temp\DCs.txt -d "ou=domain controllers,dc=vertical,dc=local" -v

Final Tips

Today we saw how AD objects look like. The ability to construct DNs gave us the key to perform our first directory exports. However using these basic export commands can return an overwhelming number of objects. In the second part of this article, we will perform more selective exports with the help of filters. Finally MS Excel and MS Access will help us review the exported results.

ExchangeInbox.com - Replacing the Exchange 2007 Self-Signed Certificate (Part 2)

Installing a new Certificate involves, creating a Certificate request on Exchange 2007, submitting the request to a Certification Authority and installing the returned Certificate on Exchange. Here is how we went about completing these steps.

In Replacing the Exchange 2007 Self-Signed Certificate (Part 1) we looked at the choice between public and private Certification Authorities CAs. For the latter, we walked through the installation of Certificates Services on Windows 2008. We also discussed the Certificate Subject, Subject Alternative Names SAN and wildcards. In this discussion we identified the need for a Certificate covering the names:
owa.exchangeinbox.com
autodiscover.exchangeinbox.com
exchsrv
exchsrv.exchinbox.local
Today we complete the discussion walking through the steps necessary for creating and installing a new Certificate.

Replacing Certificate on Exchange 2007

Installing a new Certificate in general involves these three steps:

1. On Exchange 2007 create a Certificate generation request.
2. Submit the request to the public/private Certification Authority.
3. Install the returned Certificate on Exchange 2007.

Managing Certificates on Exchange is done through the shell using the ExchangeCertificate cmdlets. For example running Get-ExchangeCertificate on my test machine I got three Certificates listed:

Normally we would only get the last Certificate, here having a thumbprint starting with C52A. The other two Certificates were created on installing the Certification Authority and are not in use by any Exchange services. We take a closer look at this Certificate identifying it using the thumbprint.
Note: This article uses Certificate thumbprints a number of times. In your case you have to replace these with the thumbprints taken from your own Exchange installation.

Generating a request involves running the New-ExchangeCertificate cmdlet. This is the part requiring most planning. Here we have to get the names right as discussed in the first part of the article. In my case I used the following cmdlet:
New-ExchangeCertificate
-GenerateRequest
-Path c:\setup\cert_request.csr
-SubjectName "c=MT, o=ExchangeInbox, ou=IT, cn=owa.exchangeinbox.com"
-DomainName: owa.exchangeinbox.com, autodiscover.exchangeinbox.com, exchsrv, exchsrv.exchinbox.local
-KeySize 1024
-PrivateKeyExportable: $true
New-ExchangeCertificate is fed with the GenerateRequest parameter showing that here we are not truly creating a new Certificate but just a request. The resulting request will be saved to disk at the specified path base64 encoded. The SubjectName and DomainName are the parameters identifying the Certificate Subject and Subject Alternative Name extension respectively.
The SubjectName is an X.500 Distinguished Name DN identifying the Certificate user (owa.exchangeinbox.com). A public CA will check this value carefully before issuing a Certificate. It is their job to make sure you are who you claim to be. If using a private CA, you would still want to choose a DN that is representative of your organization and the entity using the Certificate.
At the DomainName we just list all names discussed earlier. If using wildcards we could have instead used:
-DomainName: *.exchangeinbox.com, exchsrv, exchsrv.exchinbox.local

Running New-ExchangeCertificate successfully creates a new entry in the Exchange Certificate list. Of course we also get the request itself saved at the specified path.

We now hand the request to the Certification Authority. If using a public CA we submit this through their web interface. A private CA using Certificates Services provides a number of options. The Certificates Services web enrolment interface requires us to paste the content of the request file. In this case we would paste everything including the Begin/End header areas.
For a walk through the procedure for submitting the request to Certificates Services, check the section that follows. For the moment let's just assume we got the Certificate back ready to be installed.
We should now have one or more files covering the Certificate chain. At this point it is most convenient to work with the PKCS #7 Certificate file having an extension of *.p7b that bundles the Certificate chain in one file. With this we go back to the Exchange shell and run the cmdlet that follows. Here certchain.p7b is the file returned by our CA:
Import-ExchangeCertificate -Path C:\setup\certchain.p7b

Exchange will now install the new Certificate. In the Certificates list returned by Get-ExchangeCertificate, this will replace the entry that was created on running New-ExchangeCertificate to generate the request.
Next using the cmdlet that follows, we assign the new Certificate all the services for this Exchange server:
Enable-ExchangeCertificate
-Thumbprint 98A5897324FE8952D72FB17CE0C46365DB132A42
-services IIS, POP, IMAP, SMTP
Calling Get-ExchangeCertificate we see how the new Certificate has taken over these services.

We may finally delete the old self-signed Certificate using the command:
Remove-ExchangeCertificate
-Thumbprint C52A264821E83E92173D5E44DC3DDEE0F8CBEB2F

Submitting Request to Certificates Service

To begin, I first tried to submit the request through the Certificates Services CA MMC interface to expose a well known issue.

Selecting the 'Submit new request' task prompts you to select the Certificate request file. However on doing so we get back the error:
'The request contains no Certificate template information. 0x80094801 (-2146875391) Denied by Policy Module 0x80094801, the request does not contain a Certificate template extension or the Certificate Template request attribute.'

To avoid this problem we could use the Web Enrolment service or the certreq.exe command line application. I did the latter, using the command line that follows. Note how the attrib parameter specifies a template that was the root cause of the previous error.
certreq.exe -submit -attrib "CertificateTemplate:WebServer" c:\setup\cert_request.csr

This will prompt us to select the CA to which the request is to be submitted and finally creates the Certificate for us. We can now retrieve the newly created Certificate from the Certification Authority MMC.

Opening the Certificate we can look at its properties. The General page shows how the owa.exchangeinbox.com Certificate was issued by our newly created private CA. The Certification Path page shows the hierarchical relationship between the Certificate and the CA. This chain could in practice be composed of additional sub-authorities that form part of this chain.

The Details page shows us the various Certificate fields. Have a look at the Subject and Subject Alternative Names. See how all four DNS names are listed.

The Details page also provides the 'Copy to File' button that launches the Certificate Export Wizard. Click this and proceed to the Export File Format Page.

Here we select the PKCS #7 Certificate and also set the checkbox for including all Certificates in the certification path. Following that, proceed to the file path selection step. Specify where the p7b file is to be saved and complete the wizard.

We should now have our p7b file ready for importing into Exchange 2007 as discussed in the previous section.

Final Tips

This concludes our walk through the installation of a new Certificate. Today we saw how using the Exchange 2007 shell we generated a Certificate request, imported the new Certificate and transferred the services from the self-signed Certificate. We also looked at how a Certificate request may be submitted to the Certificates Services CA that was installed in the first part of this article.

References

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Certificate Use in Exchange Server 2007