For those getting errors trying to remove Yahoo or any other email account...
2) Connect to a wifi network
3) Restart the phone
4) Leave wifi on
5) Go to delete the account again
Thursday, November 3, 2011
Removing Yahoo Email Account on an Android
2) Connect to a wifi network
3) Restart the phone
4) Leave wifi on
5) Go to delete the account again
Sunday, October 2, 2011
Juniper SRX
Perfect example of how not to make a firewall, Juniper's SRX series...
So I've been using a legacy SonicWall that is now EOL. Worked great but I've always laughed that because I wouldn't consider it an "Enterprise" class firewall. What I needed was a firewall that could handle multiple ISP gateways and support for redundant VPN site-to-site connections. I had a CiscoASA alongside the SonicWall to handle the site-to-site VPN connections but unfortunately Cisco is still behind the times when it comes to making it work well with multiple gateways (especially an active/active configuration). What was left was Juniper, but they insisted their ScreenOS line was soon to be exitinct and their newer SRX line was just as good.
On paper, I couldn't disagree. Had everything I was looking for and more. Unfortunately, I couldn't have been more wrong. What it did support was so half-ass and buggy that I would never recommend this to anyone.
First off these SRX firewalls (I've configured the 220 and 240s, not sure if they bigger ones are any better) are nothing more than FreeBSD with a overhauled network engine. With that in mind, the CLI starts off in a shell, moves to a ScreenOS type configuration, and in the end the result looks like a Unix Shell Script to make it as confusing and bloated as possible.
So I took 3 examples of how to configure dual-ISPs online with these Firewalls. And despite their proud virtual-routing capabilities, the only benefit I experienced was using it to do workarounds for their buggy limitations. In order to use both interfaces, the VPN tunnels have to be terminated to the main routing table which makes it a bitch and a half to be usable. So weeks later and testing and trial-and-error I finally was able to have 2 VPN tunnels going out from one site terminating on the same destination at another site. Great! But it turns out their VPN tunnels are horribly unstable, if one goes down it took a total reboot of both firewalls to get them both back up. Ended up using OSPF which also caused a lot of issues I had to work around but finally stabilized the VPNs if one died.
So next I wanted to cluster them. How hard could it be right? And this is where I lost all faith in Juniper. They really shouldn't call it clustering because it takes a young priest and an old priest for it to work correctly. So lets just call it cluster fucking them. First, you need to find out exactly which ports to connect back to back (its random for each different model) then you configure these "out-of-band" ports which is really not out of band but just impacts your configuration because it conflicts with the network segment you put these in. Next you have to configure another link for the switching fabric. Okay whatever, I got through it... so I'm set right? Nope, if you want to upgrade the software on them after this point there will always be downtime. The procedure is so complicated and ridiculous that in the end the safest and easiest method was to update both the primary and backup and reboot them at the exact time. That's literally the only way to do this without worrying about breaking something. So, I guess its okay, about 5-10 minutes of downtime (reboot time).. but wait, even though its clustered if you run any UTM features (Antivirus, IDP, etc) you are limited to an active/passive configuration (where one does nothing but sit and wait around). Yet you still need a license for each feature on both firewalls even though you can't use them at the same time. Oh another gotcha, you can't really update the signatures on the standby unless you make it active. I guess that's okay, oh but wait you need a complicated script to monitor if one unit does die because by itself it won't fully switch over to the backup unit. Yuck, but I guess as long as it works... So the first day in production: unit randomly switched over to the backup cluster despite it disabling two ports on its own. It took rebooting both units to get it back to working correctly.
So in the end, despite laughing at SonicWall, I realized how much I miss the fact that it took 1/100th of the time to configure and the fact it can handle multiple ISP gateways flawlessly as well as supporting a WORKING HA configuration.
Even without such a complicated setup like dual-ISPs or clustering, Juniper's SRX are still a total joke. The latest version (11R2.4) tries to add a "global" address book feature (similar to Cisco's network-objects) but it only does a half-ass job at configuring redundant information and I still find myself putting in the same network information for NAT pools vs Policies. Even worse, it takes 3-5 minutes of just waiting (where the web interface will eventually timeout) for a configuration to commit.
Nice try Juniper, but this whole SRX line is just an example of how NOT to make a firewall.
So I've been using a legacy SonicWall that is now EOL. Worked great but I've always laughed that because I wouldn't consider it an "Enterprise" class firewall. What I needed was a firewall that could handle multiple ISP gateways and support for redundant VPN site-to-site connections. I had a CiscoASA alongside the SonicWall to handle the site-to-site VPN connections but unfortunately Cisco is still behind the times when it comes to making it work well with multiple gateways (especially an active/active configuration). What was left was Juniper, but they insisted their ScreenOS line was soon to be exitinct and their newer SRX line was just as good.
On paper, I couldn't disagree. Had everything I was looking for and more. Unfortunately, I couldn't have been more wrong. What it did support was so half-ass and buggy that I would never recommend this to anyone.
First off these SRX firewalls (I've configured the 220 and 240s, not sure if they bigger ones are any better) are nothing more than FreeBSD with a overhauled network engine. With that in mind, the CLI starts off in a shell, moves to a ScreenOS type configuration, and in the end the result looks like a Unix Shell Script to make it as confusing and bloated as possible.
So I took 3 examples of how to configure dual-ISPs online with these Firewalls. And despite their proud virtual-routing capabilities, the only benefit I experienced was using it to do workarounds for their buggy limitations. In order to use both interfaces, the VPN tunnels have to be terminated to the main routing table which makes it a bitch and a half to be usable. So weeks later and testing and trial-and-error I finally was able to have 2 VPN tunnels going out from one site terminating on the same destination at another site. Great! But it turns out their VPN tunnels are horribly unstable, if one goes down it took a total reboot of both firewalls to get them both back up. Ended up using OSPF which also caused a lot of issues I had to work around but finally stabilized the VPNs if one died.
So next I wanted to cluster them. How hard could it be right? And this is where I lost all faith in Juniper. They really shouldn't call it clustering because it takes a young priest and an old priest for it to work correctly. So lets just call it cluster fucking them. First, you need to find out exactly which ports to connect back to back (its random for each different model) then you configure these "out-of-band" ports which is really not out of band but just impacts your configuration because it conflicts with the network segment you put these in. Next you have to configure another link for the switching fabric. Okay whatever, I got through it... so I'm set right? Nope, if you want to upgrade the software on them after this point there will always be downtime. The procedure is so complicated and ridiculous that in the end the safest and easiest method was to update both the primary and backup and reboot them at the exact time. That's literally the only way to do this without worrying about breaking something. So, I guess its okay, about 5-10 minutes of downtime (reboot time).. but wait, even though its clustered if you run any UTM features (Antivirus, IDP, etc) you are limited to an active/passive configuration (where one does nothing but sit and wait around). Yet you still need a license for each feature on both firewalls even though you can't use them at the same time. Oh another gotcha, you can't really update the signatures on the standby unless you make it active. I guess that's okay, oh but wait you need a complicated script to monitor if one unit does die because by itself it won't fully switch over to the backup unit. Yuck, but I guess as long as it works... So the first day in production: unit randomly switched over to the backup cluster despite it disabling two ports on its own. It took rebooting both units to get it back to working correctly.
So in the end, despite laughing at SonicWall, I realized how much I miss the fact that it took 1/100th of the time to configure and the fact it can handle multiple ISP gateways flawlessly as well as supporting a WORKING HA configuration.
Even without such a complicated setup like dual-ISPs or clustering, Juniper's SRX are still a total joke. The latest version (11R2.4) tries to add a "global" address book feature (similar to Cisco's network-objects) but it only does a half-ass job at configuring redundant information and I still find myself putting in the same network information for NAT pools vs Policies. Even worse, it takes 3-5 minutes of just waiting (where the web interface will eventually timeout) for a configuration to commit.
Nice try Juniper, but this whole SRX line is just an example of how NOT to make a firewall.
Tuesday, August 16, 2011
Office 365 (Enterprise) problems and limitations
Everyday my list of issues and limitations grows. I would reconsider moving to Office 365 at this point, its definitely not ready for Enterprise deployments.
Update 4/5/2012: More issues I've encountered:
1. Lync (their IM solution/Goto Meeting alternate) does not support delegation in Office 365 (but is supported in their regular versions). By this I mean an administrative assistant cannot create online meetings for their supervisors.
2. I've had a problem where their database was not mounted for a user. Took 2 hours on the phone with tech support before it was finally resolved. They couldn't figure out the problem nor how it was magically fixed.
3. As a workaround for using shared mailboxes, we've been using IMAPS for our workgroups. Unfortunately they changed some server settings recently and now IMAP connections are limited to 1 concurrent session PER USER.
4. I've discovered inbetween SP1 and SP2 a lot of mailboxes have lost their GUID mapping with active directory. I've had to manually readd the GUID if the user's mailbox needed to be moved back to the on-prem Exchange servers (for example ex-employee's mailbox that needs to be backed up).
5. Archives. You cannot access archives through OWA as the user or an admin. You must make an automapped account in Outlook to access it which goes against their recommendation for shared mailboxes.
- Federation setup (aka Single Sign On) is a mess to deploy and requires an investment in servers (2 at a very minimum not including the Exchange server) and keeping them stable just to use the service. Microsoft recommends 6 servers, which at that cost and infrastructure administration it's actually cheaper and far easier to setup your own Exchange server.
- Migrating from an existing Exchange setup will limit you later on and requires a complex setup. Furthermore it's nearly impossible to administer Office 365 without an on-premise Exchange 2010 server. So don't assume you will never need to host an on-premise Exchange server once everything has been moved over.
- Problems with DirSync's one-way push breaks a huge amount of functionality. For example, you cannot use self-managing distribution groups they way they were intended. All changes have to be done by an admin to the local active directory then pushed to Office 365.
- The "free" licenses for Room/Shared mailboxes must be created on Office 365 -- migrating them from an existing Exchange server is a disaster and extremely buggy.
- The free "Shared" mailbox limitations are overwhelming. You cannot use IMAP/POP3 and they have to mapped through the users Mailbox account. Because of this, you cannot create mail rules since you do not have the ability to login directly to the mailbox. The OWA/web-version rules are nearly useless (can't create autoreplies/forwarding/etc).
- Migrating mailboxes is hit or miss. About 1 in 10 of our migrations (300 accounts) have encountered errors where email properties are not updated causing duplicate mailboxes on both the on-prem server and on Office 365. Without dirty hacking ADSI, the only fix is to completely remove both emails accounts and start over (which makes a huge mess for users since replies from their old emails will bounce due to broken x400/x500 and GUID differences).
- Tier 1 support is absolutely useless. I have 25 open tickets (some 2+ weeks old) and their replies have never resolved anything. Sadly, unless you request escalation they will respond with completely irrelevant links or information, then request you update the ticket since to them it looks like the ticket is now waiting on you.
- Mobile device support is disappointing. Blackberry devices are not supported at this time. Android phones running 2.3+ cannot sync with their servers (yet worked fine with Exchange 2003/2007)...
- If you are running any LDAP mail-lookups you will find sometimes its impossible to replicate some email address you have in Office 365 back to your local Active Directory. So if you plan to use this with a local Sharepoint on-site, think again. Same goes with using their server as an SMTP gateway. They require TLS encryption with an existing account, so using it for your scanners or email alerts will require you to run your own local SMTP gateway.
Update 4/5/2012: More issues I've encountered:
1. Lync (their IM solution/Goto Meeting alternate) does not support delegation in Office 365 (but is supported in their regular versions). By this I mean an administrative assistant cannot create online meetings for their supervisors.
2. I've had a problem where their database was not mounted for a user. Took 2 hours on the phone with tech support before it was finally resolved. They couldn't figure out the problem nor how it was magically fixed.
3. As a workaround for using shared mailboxes, we've been using IMAPS for our workgroups. Unfortunately they changed some server settings recently and now IMAP connections are limited to 1 concurrent session PER USER.
4. I've discovered inbetween SP1 and SP2 a lot of mailboxes have lost their GUID mapping with active directory. I've had to manually readd the GUID if the user's mailbox needed to be moved back to the on-prem Exchange servers (for example ex-employee's mailbox that needs to be backed up).
5. Archives. You cannot access archives through OWA as the user or an admin. You must make an automapped account in Outlook to access it which goes against their recommendation for shared mailboxes.
Subscribe to:
Posts (Atom)