We stopped supporting BES (Blackberry Enterprise Server) and Exchange a long time ago due to its cost, stability, and complexity. We know lots of folks are fans of Blackberry’s so we looked all over for an alternative.
AstraSync is what we found and have recommended to our clients for years. It works well and our Blackberry users are happy with it.
Hopefully one day Blackberry will just license ActiveSync like Apple’s iPhone did, but for now, AstraSync works great and is cost-effective considering the alternative.
So if you need your Blackberry to talk to Exchange, get AstraSync and move on to more interesting things 
If you want to use a GoDaddy UCC certificate with Exchange 2010, you’ll run into a few problems using the new certificate GUI tools.
Since GoDaddy does not provide a PFX certificate to download, you have to use the PowerShell command line.
Though you can use the new GUI to assist you in determining which SAN names you need if you want.
MY ADVICE: make your common name just your top level domain name! (ex. montopolis.com) This way you can change out your SANs easily and rekey when needed.
Go to DigiCert’s Exchange 2010 CSR Tool which is just supper handy (GoDaddy really needs to make a version of this tool).
Enter all of your information and click Generate.
Copy the PowerShell code provided into Notepad.
In front of the code you pasted put in “$Data=” (without quotes). Example:
$Data=New-ExchangeCertificate -GenerateRequest -KeySize 2048 –SubjectName…………………
On the next line enter the following (without quotes)
set-content -path “mycommonname.com.csr” -Value $data
Now paste these two lines into your Exchange Management Shell.
You should now have a mycommonname.com.csr file!
Open this file in notepad so you can copy & paste this for GoDaddy.
Go to https://certs.godaddy.com and request a new UCC certificate. When asked paste your CSR.
Wait for GoDaddy to issue your cert and download it for Exchange 2007. Copy the contents of the ZIP into the directory where your CSR is located.
From the Exchange Management Shell type in, replacing mydomain.com.csr with your filename:
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path mydomain.com.crt -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate -Services “IIS”
Don’t worry about the services enabled right now. We just want to enable one.
Now start your Exchange Management Console –> Server Configuration. You should now see your new certificate listed. Select it and click Assign Services to Certificate from the Actions menu.
Now assign the certificate to the services you want and voila!
I wasted a couple hours going the wrong way so I hope this saves someone else some time and frustration. Good luck!
As a benefit of the American Recovery and Reinvestment Tax Act of 2009, beneficial provisions of IRC Section 168(k) (relating to bonus depreciation) and Section 179* (relating to increased deductions) have been extended for new equipment and software placed in service.
* The extension of these provisions results in potentially lucrative tax breaks for eligible technology purchases. Bonus depreciation is available for all businesses and provides an immediate depreciation deduction of 50 percent of the cost of new equipment and software placed in service during calendar year 2009. For taxable years beginning in 2009, 100 percent of new equipment and software purchases up to $250,000 can be expensed immediately. To limit this benefit to small businesses, the maximum immediate expense amount is reduced dollar-for-dollar to the extent that a taxpayer’s total new equipment and software purchases for the year exceed $800,000. (None of this information should be construed as or constitutes tax advice—please consult your tax adviser for a complete and detailed analysis.)
For more information on this tax break visit the IRS website.
Once we introduced Windows 7 systems to our network, our GPO to set the screensaver and lock the system after 15 minutes stopped working.
A Google search only relevantly led me here:
http://blog.mpecsinc.ca/2009/05/windows-7-no-logon-screen-saver.html
So after some leg work, here is the GPO you want to create & use now.
Create a GPO Link and set it up as follows:
Let GPO replicate or gpupdate /force it.
Tested on Windows 2003, XP, 2008 & 2008 R2 & 7. Not tested on Vista, assume it’ll work.
If you want more granular control you can create WMI filters. This nice article Creating WMI and Group Filters for 2000, XP, 2003, 2008, Vista, 7, 2008 R2 is right from the documentation gods @ Microsoft!
Ok all you developers out there…
I don’t care what language you write in or how good you think you are, there are some basic rules for sending email that seem to be continuously neglected which only causes unecessary drama for everyone around you.
I don’t care if you’re an internal/intranet developer, or work for eBay. It’s the same basic rules.
Being both a developer and a mail admin myself, I know this stuff gets complicated real fast. And I’ll also assume you haven’t been trained better.
So assuming you want to keep on developing code, here is what you should know…
1. ALWAYS follow ALL of the rules below
a. Whether sending 1 email or 60,000, the rules are always the same – no shortcuts!
2. ALWAYS authenticate, if you have the option!
a. Security is always important. Having proper permission to send/relay email is step 1, not step 99.
3. ALWAYS use SMTP TLS/SSL, if you have the option!
a. Again security is important, and you don’t want to be the developer who allows highly sensitive data and/or credentials to be read by a 12 year old, with a free network sniffer (http://www.wireshark.org/ or http://blogs.technet.com/netmon/), and then posted on MySpace.
b. No matter what you’ve heard, it’s too darn easy (and fun) to sniff network traffic.
4. ALWAYS specify a proper email subject, even during testing.
a. Blank subjects are bad form (see #6) and plain useless to all concerned.
5. ALWAYS insure a valid FROM and/or REPLY-TO email address.
a. Bogus data here increases the possibility that a server you are sending through can get blacklisted (worst case) or just poor email delivery (best case).
6. ALWAYS well form all emails sent, especially if you’re including attachments.
a. Using a good class (which is maintained by folks who know better) usually resolves this. Otherwise same concerns as #5.
b. If you aren’t using a class, then I expect to you to understand and have memorized all of these RFCs: RFC 821, RFC 822, RFC 2821, RFC 2822, RFC 2487, RFC 2045, RFC 2046, RFC 2047, RFC 2048 and RFC 2049
7. ALWAYS consider how to handle send failures in the event you are developing synchronous code.
a. If you are asked to write code to send an email, presumably the recipient is expecting one.
b. Failing to properly handle errors means that the recipient is left hanging which only leads to a shortened development career.
8. ALWAYS insure you can enable and see debugging internals of your mail code.
a. You can’t blame the mail admin folks if you have no idea what your email code is ACTUALLY doing.
b. They can’t AND won’t help unless you can provide PROOF of what is failing – they need to see the entire transaction. It’s the whole needle in the haystack thing. No mail admin wants to dig through a billion lines of logs to find your dumb mistake.
9. ALWAYS consider your email send volume and plan accordingly.
a. Don’t assume you’re allowed to send 6 million emails – you’re not. When in doubt ASK.
b. Network throttling and limiting is implemented for a valid purpose – to keep bad stuff from happening. You know the Vulcan saying… The needs of the many, outweigh the needs of the few, and YOU!
c. Uh bandwidth costs money. Even if you’re not paying for it, someone is. And that someone will find you (or worse your boss) and get the money and/or pounds of flesh. Unless you’re the developer writing the next version of Google Earth or Microsoft Word, you can expect it.
I won’t even go into how to properly test your email code before going into production, because I will assume you can take it from here. Right?
Those are the basics. Learn ‘em, live ‘em, love ‘em.
