Google Apps Sync for Microsoft Outlook disables Outlook to search the Outlook data

Google Apps Sync for Microsoft Outlook disables Outlook to search the Outlook data: "Google Apps Sync for Microsoft Outlook disables Outlook to search the Outlook data"

I installed the Google Sync tool playing around with migration scenarios and sure enough realized after the fact that the Outlook indexing/search registry key was added. Sounds like a buried issue for end users down the road.

Complete hard disk recovery solution, backup, drive copy, clone and image computer software

A couple of months back I invested in Acronis Home 2009. This has proven to be a great investment. I have utilized the software to do full disk 'image' backups to external harddrive. This is allowing me to breath easier when I detect some type of browser hijack attempt or any other general issue such as disk failure or whatever. I shoot an incremental update to the image about once every two weeks.

The software has several features I haven't even gotten around to investigating, but I have used it to push back images (some testing, some for break-fix) successfully.

If you purchase it, make sure to burn the 'recovery' CD. It gives you the option to fully recover even in the event of a complete harddrive crash where you have to replace it with a new drive.

www.acronis.com

Complete hard disk recovery solution, backup, drive copy, clone and image computer software: "Acronis True Image Home 2009 is an award-winning backup and recovery solution for a good reason: it protects your PC after just one click and allows you to recover from viruses, unstable software downloads, and failed hard drives. Create an exact copy of your PC and restore it from a major failure in minutes, or back up important files and recover them even faster."

Backing up the cheap way

I was scared back into thinking about desktop backups a couple of weeks ago. As is normally the case, I purchased a new external hard drive to 'backup' my data. Then as I created more docs, archived more e-mails, etc. this disk became just the storage place for this data. To keep the desktop clean, I moved data to the external hard drive and purged it from the desktop. I know… I know… this is terrible document protection, but laziness and lack of space created this situation.

 

The external hard drive was used for some servers builds and the file table got jacked up. With the prospect of losing all this data, I went into panic mode and started using serious data recovery tools and days of different attempts to recover the file table and retrieve the docs (including 7 years of Outlook PSTs). This finally spurred me to implementing a more stable data protection methodology. For my benefit and anyone that happens across this, I will detail what this poor man's backup solution looks like.

 

The overview:

• Use NTBackup (cuz it's free)
  
• Purchase second external harddrive with sufficient space for multiple full backups of necessary files (in this case a USB 2.0 500GB HD)
  
• Configure NTBackup to perform nightly backups
  
• Use batch files to initiate backups and purge the previous night's backup when tonight's completes (I know there is no logic in this file to ensure a successful backup before purging last night, but it is better than nothing. This is the cheap solution and was set up in about 30 minutes.)
  

Note: for this example my drives are laid out as

• C: - local internal hard drive
  
• E: - 300GB external data drive
  
• D: - 500GB external backup drive (dedicated to backups)
  

 

 

Create a backup definition file (.bks):

This file details what directories (and/or files) will be backed up. This is not the actual job. The job is created later. Here is an example of the contents of my .bks file.

"Daily Desktop backup.bks" –

C:\Documents and Settings\wrightke.MYCOMPANY\My Documents\

C:\accounts\

C:\backup of laptop\

C:\CAConfig\

C:\certs\

C:\cluster\

C:\documents\

C:\iso\

C:\lcs\

C:\lifeway\

C:\NBD\

C:\scripts\

C:\software\

C:\sysprep\

E:\

 

 

Create seven daily backup batch files:

I have seven files named by day (Sunday.bat, Monday.bat, Tuesday.bat, etc.) that define the job for that day. The file calls the backup definition file, the configurable options for ntbackup, and then after the job completes, deletes the backup file from the previous day.

For instance, Sunday.bat will run and create a new backup named Sunday.bkf. At the end of the backup, it will delete Saturday.bkf. Monday then creates Monday.bkf and deletes Sunday.bkf.

Contents of Sunday.bat –

@echo off

C:\WIN2K3\system32\ntbackup.exe backup "@C:\Documents and Settings\wrightke.MYCOMPANY\Local Settings\Application Data\Microsoft\Windows NT\NTBackup\data\Daily Desktop backup.bks" /n "Daily Desktop backup" /d "Set created 5/23/2008 at 2:00 AM" /v:yes /r:no /rs:no /hc:off /m normal /j "Daily Desktop backup" /l:s /f "D:\ntbackups\wrightke02\Sunday.bkf"

del "D:\ntbackups\wrightke02\Saturday.bkf"

 

So you can that the Monday version just changes two file names (the .bkf file references). Just make sure you are creating a new job and deleting yesterday's. If you don't get it right, you could create Monday.bkf and then immediately delete Monday.bkf. That would defeat the purpose.

 

Create seven recurring tasks in Windows Task Scheduler:

The scheduled tasks are named by day (Sunday, Monday, Tuesday, etc.). The job calls the .bat file for that day, such as Sunday.bat. The job is set up to occur weekly, on the day that corresponds with the batch file. It is scheduled for 2:00 AM as that is probably the least likely time I will be on the machine. So task "Sunday", executes Sunday.bat and runs each Sunday. I chose to set it to stop if it runs longer than 10 hours. I also chose to remove the checkmarks that talk to starting on battery power or starting while the machine is asleep. This is a desktop so those don't really apply.

I plan to check this at least once weekly for continued operation, but I have not set up any auto-notification of completion or anything. This is just my backup copy. I also have started doing a monthly flat file copy to the external hard drive as well. So I am keeping two backups more or less.

 

Note: this machine is a domain member, so I chose to run the job as the local administrator instead of with domain credentials. The local system does not expire local accounts. However, my domain account does expire every 45 days by policy. I have dealt with scheduled tasks enough to realize that expiring passwords do not work well with these tasks.

 

Final note: Some of the files addressed with this backup are Outlook PST files. If I leave Outlook open, there will be conflicts with open files. Those are some of the more 'critical' files I would like to backup. To mitigate this, I borrowed a vbscript from the internet. I have scheduled this vbscript to run daily five minutes before the daily backup kicks off. Here are the contents of the script:

 

Set objShell = CreateObject("WScript.Shell")

Set objWmi = GetObject("winmgmts:")

 

 

strWmiq = "select * from Win32_Process where name='Outlook.exe'"

Set objQResult = objWmi.Execquery(strWmiq)

 

 

For Each objProcess In objQResult

intRet = objProcess.Terminate(1)

Next

Exchange Design process

I am in the midst of a documentation marathon. I have created a template document and pasted Microsoft Exchange 2007 web documentation into that Word doc. It started at 715 pages and I have begun adding my specific design statements and decisions to this doc for the current process. I am 320 pages in and the first draft is due Friday. I am on mile 10 and already feeling winded. As long as I keep running and delay pass out, until I can pass out and fall over the finish line.

Guitar Hero update

Just a minor GH update, but I have completed 30 songs (out of 40) on the "Hard" level and 6 songs on "Expert". I went back and got five stars on all except 3 songs on the "Medium" setting. Why do I care? I am a grown man with children. Why am I playing this video game?

ISA Load Balancing decisions

More copy and paste from documentation.

 

Web server farm load balancing enables administrators of Microsoft® Internet Security and Acceleration (ISA) Server 2006 to publish a farm of Web servers performing the same role, or hosting the same content, to do the following:

•	Implement load balancing to distribute requests evenly among available servers.
•	Detect offline servers and implement consistent failover.
•	Allow draining, removing, and adding server farms without disrupting current connections.

 

Web servers are grouped into a farm by creating a server farm object. ISA Server treats all the Web servers in the farm as a single entity. When you create a Web server farm, you specify the following:

•

The computer names or IP addresses of Web servers to be included in the farm. Computer names must be resolvable to IP addresses.

•

A method for monitoring connectivity to each server in the farm. Methods include a URL request, a PING request, or a TCP request to a specific port. Based on the method you choose, ISA Server automatically creates a connectivity verifier for each server in the farm. All servers in the farm use the same type of connectivity verifier. A connectivity verification request is sent every 30 seconds to each Web farm member, and the response time is compared with a default time-out response threshold of 5,000 milliseconds. ISA Server uses the response to determine the state of servers in the farm. Note the following limitations when selecting a URL request as the connectivity method for Web farm monitoring: • URL requests are supported for Web servers whose names contain English characters only. • The URL you specify should be prefixed with an asterisk (*). ISA Server will replace the asterisk with the name of each server in the farm. For example, if you have a farm with servers A and B, and you specify http://*/status.htm as the URL, two connectivity verifiers will be created: http://A/status.htm and http://B/status.htm. • In most cases, you must enable the system policy rule Allow HTTP/HTTPS requests from ISA Server to selected servers for connectivity verifiers. However, if you specify a nonstandard port in the URL (for example http://*:88/status.htm), the predefined system policy rule cannot be used. Instead, you must create a custom access rule to allow HTTP and HTTPS traffic from ISA Server to the Web farm on the custom port. • When configuring a URL request, you can specify a custom host header to be included in the connectivity verification request. This is useful if a Web application published by the farm requires a specific host header.

 

Load Balancing Affinity

ISA Server can use session affinity (cookie-based load balancing) or IP affinity (source IP-based load balancing) to implement the load balancing algorithm.

Session affinity

The aim of session affinity is to evenly spread client sessions (where a session is a number of consecutive Web requests that share the same TCP connection) among Web farm members. Session affinity does not support an uneven distribution of requests (for example, 50 percent of traffic to Server 1 in the farm, 20 percent of traffic to Server 2, and so on). Instead, session affinity uses a round-robin mechanism to ensure that browser sessions with a Web application serviced by a Web farm are distributed fairly among farm members that are online.

All replies to HTTP requests originating from a client browser session are sent to the original client. We recommend that you use session affinity when possible, because it provides more reliable client affinity when a Web server is restarted. This is sometimes referred to as client stickiness. Stickiness is ensured using a cookie inserted by ISA Server in the response to client requests. The cookie is sent by the client's browser in further requests and indicates to ISA Server which server in the farm to connect to.

Session affinity is suited to publishing Outlook Web Access servers and Microsoft Windows® SharePoint® Services sites. It is not useful in Exchange RPC-over-HTTP publishing, where the client application is an instance of Outlook rather than a Web browser, and cannot handle cookies.

IP affinity

The aim of IP affinity is to evenly spread requests from different IP addresses among Web farm members. The even spread is preserved during failover. For failover, servers that are not responding are detected, and load distributed among available servers. ISA Server administrators can remove a server from a farm in a two-step process without disconnecting existing client requests.

IP affinity should not be used when remote clients are located behind a NAT device, or if ISA Server functions as an upstream server, and sees only the IP address of the downstream ISA Server computer. In this case, you should use session affinity only.

IP affinity is particularly useful in an Exchange RPC-over-HTTP scenario, where session affinity cannot be used because cookies are not supported by the Outlook client application.

 

Draining and Removing Servers

Prior to taking down a server for maintenance, you should set the state of a Web farm member to Drained. For session affinity, the server will continue to handle current client sessions, but will not accept new ones. When offline servers come online again, they are again included in the round-robin algorithm. For IP affinity, a drained server stops receiving requests, but existing connections to that server are maintained. After draining a server, you can perform the required maintenance and then resume the server in the array, or remove it from the farm.

 

To publish a farm of Outlook Web Access servers or Outlook RPC-over-HTTP, use the Exchange Web Client Access Publishing Rule Wizard.

 

When you configure a Web farm in an HTTPS-to-HTTPS bridging scenario, you can deploy a unique certificate on each server farm member, or use a single certificate for the Web farm object. If you use a single certificate, you must use the internal name specified in the publishing rule as the common name when creating the certificate

Even if you do not need to make a Web farm available internally or account for link translation, the ISA Server rules engine needs to resolve the internal site name. In this case, we recommend that you set the internal name to the Domain Name System (DNS) name of one of the servers in the farm.

 

 

Load Balancing in Secure Publishing Scenarios

When load balancing HTTPS requests for Web farm resources, note the following:

•	Load balancing is not supported for Secure Sockets Layer (SSL) connections tunneled through ISA Server (server publishing). It is only supported in Web publishing, when the HTTPS connection is terminated on the ISA Server computer, and then forwarded over HTTP or HTTPS to the Web farm (HTTPS bridging).
•	For HTTPS bridging scenarios, both IP affinity (source IP-based) and session affinity (cookie-based) are supported.
•	In an HTTPS-to-HTTPS bridging scenario, the servers in the Web farm authenticate to the ISA Server computer with a server certificate. You can deploy these certificates as follows: • Deploy a server certificate on each server in the Web farm. For example, if the server farm consists of Server1.internal.net, Server2.internal.net, and Server3.internal.net, you must acquire a unique certificate for each server, with the name of the farm member as it appears in the server farm object. • Alternatively, deploy a server certificate for the Web farm object. In this case, you acquire a certificate with the internal name you specified for the Web publishing rule for the farm, and deploy the certificate on each server in the Web farm.

 

 

 

Adding this just due to the fact that this is something that could easily be forgotten. In the interest of reducing overhead, clear text (port 80) traffic could be employed between the ISA and the CAS server. However, if Basic authentication is used, this results in clear text passwords being transmitted across DMZ and internal LAN networks.

To publish a farm of Outlook Web Access servers or Outlook RPC-over-HTTP, use the Exchange Web Client Access Publishing Rule Wizard.

Interesting bits from ISA documentation

Pulled some items worth review from the ISA documentation. Here are some sizing parameters and other random pieces that jumped out today:

 

Using the /3GB Boot.ini Switch

For large systems with over 2 GB of memory, Windows Server 2003 and Windows 2000 Advanced Server offer the 4GT RAM tuning feature. This feature divides a process memory space into 3 GB for application memory and 1 GB for system memory. This feature enables processes to benefit from more than 2-GB RAM in user space, and is enabled by adding the switch /3GB to the Boot.ini file. (For details, see article Q171793, "Information on Application Use of 4GT RAM Tuning," in the Microsoft Knowledge Base.)

This feature may be beneficial for ISA Server, especially for reverse caching hosting a large Web site. However, using this feature reduces the maximum size of the nonpaged pool (to 128 MB instead of 256 MB), hence the maximum number of concurrent TCP connections.

 

MSDE logging vs. File logging

In comparing the two methods, MSDE has more features, but it uses more system resources. Specifically, you can expect an overall 10 to 20 percent improvement in processor utilization when switching to file logging from MSDE.

 

Connections and some virtual stats

Measurements of a remote procedure call (RPC) over Secure HTTP (HTTPS) publishing scenario on a dual-core, dual-processor 2.2 GHz server with 8 GB of RAM showed the following:

•		A single installation of ISA Server on a host computer handled 40000 concurrent connections with approximately 2 GB of virtual memory.
•		Three ISA Server computers installed on three virtual operating systems handled 60000 concurrent connections with only 1.3 GB used by each virtual computer. This model could be scaled out to more virtual computers (for example, four, eight, and so on) depending on the amount of RAM and the processing power of the hosting server. The tests were run on three computers.
•		CPU utilization in both cases was almost the same.

 

Scaling Out ISA Server - Using Windows Network Load Balancing

NLB is implemented at the operating system level. It provides evenly distributed load balancing and supports fault tolerance. (Other servers in the cluster can detect a failing server and distribute its load between them.) However, it requires CPU processing overhead (approximately 10 to 15 percent for common ISA Server scenarios), and has a limit to the number of members in the cluster (approximately 8 computers as the recommended maximum).

 

NLB requires 15 percent performance overhead when enabled. An NLB array with a single member will perform 15 percent less than the same array with NLB disabled. Therefore, when estimating capacity with NLB scale-out, it is necessary first to factor down the throughput values for a single computer by 15 percent, and then apply the scale factors.