Practical Technology

Well, in the end we decided to hold off on the Office 365 decision, at my recommendation.  It really came down to what was best for the company right now. There are important lessons here: Do your due diligence, investigate the options, speak to multiple vendors - you will learn something, and might even be able to save the company some serious money If you don't have the time to do one migration, don't try and do three at once As an admin, you only see a small part of the picture - get everyone (all stakeholders, as they say) involved IN PERSON MS Project - get all PM stakeholders involved IN PERSON to decide what the company really needs - there are other (and much cheaper) alternatives If you don't have the budget for a migration tool, you should revisit the impetus to migrate Regarding the last point - no, you don't NEED a migration tool.  Here's another list: If you don't have the budget - will you ever?  Are you trying to rush without some

I was reading some CloudStack items on this guy's blog and came across this post (  http://kirkjantzer.blogspot.ca/2013/06/next-generation-storage-wherefore-art.html  ).  A lot of this resonates with what our company is trending towards. As a software developer, the different build stages all require complete and dedicated environments. Dev QA/UAT Prod When it comes time to build a new product for a new customer, a new set of environments needs to be spooled up.  Traditionally, everything was scratch built (VM templating being the best automation in use today) meaning a dev environment rollout could take a week or two: Lay out environment as per architecture's design Figure out networking/auth structure Deploy VM templates Install/configure IIS/SQL Deploy starter software packages Create/test public (if required) accessibility Hand over access to the dev team Wait for them to sign off Double-check that all relevant info documented There is plenty of room

As admins, knowing what's going on and why is part of our job.  Blah blah.  Here's my new list of free tools I install whenever I change companies. Create VM templates (CentOS for management & properly licensed Windows Server OS with the usual template stuff) Mgmt. server 1: IPadmin & mediawiki - document IPs, processes, etc Mgmt. server 2: nagios & smokeping Mgmt. server 3: syslog server KeePass RSAT tools SQL Mgmt Studio Royal TS (ok not free, but the best RDP manager I've found) If you are being asked to do admin & helpdesk duties: InfraDog for the DCs and vCenter Why have three mgmt. servers?  Nagios/smokeping will probably require dedicated firewall rules, and always good practice to keep your monitoring tools away from normal servers.  IPadmin/mediawiki can really sit on any Apache box.  Syslog should be kept separate for the same reason as Nagios, and IO loads. With all of that, not much you won't be able to do! One other ite

It uses Echoping, but not the standard build you can get from yum.  You have to build it using the '--with-ssl' switch (double-hyphen before 'with'):  ./configure --with-ssl https://github.com/bortzmeyer/echoping/blob/master/SRC/INSTALL Download the latest from SourceForge or wherever, un-tar, cd into that dir. wget http://sourceforge.net/projects/echoping/files/echoping/6.0.2/echoping-6.0.2.tar.gz I am running a basic server installation of CentOS6.4, I've only installed Nagios and Smokeping (and their dependencies).  The configure script also required the following packages installed via yum: openssl-devel.x86_64 openssl.x86_64 libidn-devel.x86_64 libidn.x86_64 popt-devel.x86_64 For those unaware, Smokeping has the native ability to utilize Echoping, but requires the binary at /usr/bin/echoping.  If you've already installed Echoping, just build as above and copy the new binary in. Otherwise when you run something like below, you get:

Since I'm the family IT person, I'm setting up everyone on Avast (unfortunately MSE is going away). Avast has a handy 'hay IT guy, you have a virus' alerting system, but it's a teensy bit buggy.  Mostly silent timeout periods that make it look like nothing is working.  Here's how to get it working with Gmail. Here's what you need: E-mail (SMTP) address, username@gmail.com or whatever your Gmail account is SMTP settings are... Server: smtp.gmail.com Port: 465 Security: SSL/TLS From address: I used... firstname.avast@domain.com Check 'requires auth' Enter your gmail sign on stuff The obvious flaw in this is if I ever change my gmail password, I have to make the rounds with family.  But that's ok.  I'm thankful that the feature even exists. edit:  Oh, and the settings I changed: Only using browser and file AV Fully auto updating across the board Silent mode across the board Email alerting (under 'antivirus' set

I'm writing this out because it took me ages to get even a hazy answer. TL;DR: Project On-prem is 30-50% cheaper, depending on a 2- or 3-year license lifecycle and of course your availability requirements - assuming ~85 users. Scenario Company has project managers using Project Pro 2010 and other users who enter timesheet info into PWA.   The PMs make up ~10% of the userbase.  Project Server 2010 set up in a somewhat arcane 'all-in-one' box (IIRC, the demo configuration not recommended for production use).  The company is coming up to a licensing refresh and wants to know if they should look at Office 365/Project Online.  It's the thing lately, right? Ok, sure...I've already discussed the Office portion being a no brainer for SMB, so Project must also fall under that.  By my wording you already know this is not the case. Project Online The licensing is somewhat simple: PWA users = Project Online subscription Midsize subscription + SharePoint Online 2

It's pretty simple for the Linux gurus I'm sure...but I ran into the following scenario with one of my clients. Longtime Linux admin leaves - he built all the systems - and a temp admin takes over (part of a takeover).  New management decrees security policies, so he resets all of the old ssh account passwords - the changes are not documented.  The takeover falls apart, the temp admin is no longer an employee, and control is handed back to the original company.  They are left with no admin, and no passwords. The original admin did a great (maybe slightly paranoid) job of setting up and hardening the servers, so of course root has no ssh.  This can be overcome by logging on to the console, no problem. One of the other projects the original admin set up was a couple of KVM clusters - they worked great, but one cluster had weird issues (probably hardware/networking, but the original admin left before it could be resolved), and since the temp Linux admin couldn't figure t

Preface: No, they have not solicited me. This was one of the recommended migration tools for SMB moving on-prem Exchange into Office 365.  I wanted to move one of my clients (3 mailboxes) into O365 for the simple reason that SBS2011 was a clunky beast and the thought of maintaining reliable backups for years to come was becoming something of a bogeyman to me.  Email is the only real SBS function they used (remote access portal, too), and they were needing new hardware and Office licensing...so O365 was a no-brainer. Back to the tool...this is probably one of the best admin tools out there - the troubleshooting aids they give you are second to none.  No more 'oh, sorry, it failed' messages with no real indication what went wrong.  They give you a list of steps to try to fix likely issues, a list to go through PRIOR to migrating, and if all else fails a direct email submission to support with a raft of dropdown boxes and info fields. Check these help articles (linked direct

I'll keep this short - if you are using IE11 and connecting to SharePoint 2010, you might get mysterious 'the page loads for 0.5 seconds, then you get a server-side (IIS) 404 message. Compatibility Settings -> Add domain to the list Site immediately (no refresh, no reload) comes back up. One of my clients runs SBS2011, the remote access portal login page loaded fine, but once you logged in the above behaviour manifested itself.  We had another user experience the same thing with a Project Web App (2010) site.

I was posting a reply on this thread (  http://thoughtsofanidlemind.com/2013/04/29/upgrading-office-365-wave-15/  ) and decided it merited a blog post.  If you think I'm out to lunch, please comment with intelligent arguments. The comments bring up interesting points (nearly all surrounding large-enterprise (1000k+ seats) or sub-25 user - i.e. Small Business), but the most vocal were ardently in the on-prem camp because of this math: SuperExchangeMan = $150k/yr  Cloud = $200k/yr Therefore, you get SuperExchangeMan and a $50k savings (read: cloud is more expensive, bottom line).  I'd like to think they are simply leaving out the fact that they must have Ironport/compliance functionality, on-prem anti-spam, etc, therefore THAT's why cloud is more expensive, but they were really harping on the above math. So what are they missing?  On-prem licensing & soft costs.  Sure, it only costs $x salary (haha for $150k? I guess normal for Enterprise?) for SuperExchangeMan, b