Tech Tips for Techs: Your go-to site for an unbiased opinion on comparing antiviruses

Standard

 

logo

Today I was asked the question: “Which free AV should we install for a company?” The company was in a bind and was not prepared to purchase a quality antivirus solution just yet. However, which product should they choose? I thought about this a minute, and then remembered a site that was recommended to me a while ago by a friend: www.virusbtn.com. This site is great for technicians looking to see the latest antiviruses on the market and compare results in order to make the best, most informed decision on which antivirus to choose.

On this site, you can take a look at how all of the known antiviruses stack up against each other. Click on the VB100 tab, and then go to latest comparative. This shows a handy graph used to compare reactive and proactive detection. Here is the graph for the first half of 2014:

RAP-quadrant-Dec13-Jun14-1200As you can see, some of the best AVs for the ratio of proactive/reactive ratio are TrustPort, Wontok, and G Data.

This site also has a comparative list for the VB100 results. Go to VB100 –> Recent Test Summary, and from there you can choose the various products you are thinking about by hitting the + symbol on the products you are interested in, and then clicking the GO button at the top once the products are populated. This allows you to easily go back and forth between at least two AVs, to determine which works best for you.

VirusBTN also compares spam filtering software, as well, under its VBSpam tab. It is very similar to the VB100 tab, and is a great solution for comparing spam filtering software.

The site also features tons of resources and news for the security community, and much more. When needing a good, honest opinion on antiviruses, I highly recommend reviewing this site first.

If you are not a tech, and you are ready to choose an AV that is right for you, feel free to reach out to our techs at Everon IT for assistance at 1-888-244-1748.

 

Tech Tips for Techs: Applying Office 365 licenses in bulk using Powershell

Standard

 

In this TechTip, I want to cover an issue that’s come up several times in the last few weeks for some of our larger customers. When you’re dealing with a user base in the thousands, user and license management in Office 365 can become quite a tedious task, if you’re using the GUI. Impractical, in fact. So we use Powershell to help us with these requests. Below, I’ll show you a couple of scenarios that I’ve run across and what I’ve done to solve them.

Scenario 1: A company just purchased Office 365 services – 4800 seats of E3. Their IT department has just created all 4800 users in 365, but now needs to assign the purchased licenses to those users.

After you connect to 365 with Powershell, you’ll want to first verify the license types available on your account.

Get-MsolAccountSku

In the context of this scenario, our output should look like this:

14-0922_1

ENTERPRISEPACK is 365-lingo for an E3 license. Confirming that this customer has the correct number (and right type) of license they’ve paid for, we can now proceed with assigning them wholesale to the entire organization. Since we’re dealing with such a large number of accounts, we also need to tell Powershell to give us all the results prior to piping them into the subsequent assignment command.

Get-MsolUser -All | Set-MsolUserLicense -AddLicenses "ENTERPRISEPACK" -Verbose

A caveat here… the SKU ID can vary even with the same license type, depending on whether you have 365 direct with Microsoft or if you’ve purchased it from a reseller. You’ll want to change the wording between the quotes to reflect EXACTLY the output you received from the Get-MsolAccountSku cmdlet.

Assigning 4800 licenses took quite awhile, so I left Powershell to do its business while I grabbed a cup of coffee.

 

Scenario 2: A company has had Office 365 for a few months and has experienced rapid growth in that time. They find themselves needing more licenses and also wanting to add archiving capability to their current infrastructure.

Using a similar process as in the first scenario, we need to confirm the current environment.

Get-MsolAccountSku

14-0922_2

STANDARDPACK is 365-lingo for an E1 license. We see that they have 600 of them assigned, but have an additional 168 that they’ve purchased. We can also see that they’ve purchased a matching number of Exchange Online Archiving (addon) licenses that they wish to assign as well. As a matter of due course, we’re going to add a few extra parameters to the cmdlet just to make sure that we only assign the Archiving Addon licenses to those users who only have an E1 license.

Get-MsolUser -All | Where-Object {$_.licenses[0].AccountSku.SkuPartNumber -eq "STANDARDPACK" -and $_.IsLicensed -eq $True} | Set-MsolUserLicense -AddLicenses "EXCHANGEARCHIVE_ADDON" -Verbose

This code will parse the existing user list, grabbing only those who are assigned an E1 license, and then will subsequently assign the Exchange Archiving license to those matching that criteria.

 

Tech Tips for Techs: Little-known, extra steps for CryptoWall and Cryptolocker cleanup

Standard

html-file-thmb

Hello all! Today I would like to contribute some information to something we had previously put out when talking about CryptoWall and CryptoLocker. The previous blog posts talked about the virus itself and what actions to take if you become infected with it. In addition to that, I would like to provide instructions on what further actions to take.

Today I received a call from a client, on whose system I had recently cleaned up an infection and restored their data from a backup. She told me that the computer that had been the original culprit was popping up once again with the decrypt instructions, and she was concerned that it was infected again. She took the actions I told her to take, to disconnect the network drive so it wouldn’t spread. I jumped on that machine and, sure enough, the web page had returned.

I scanned the computer with a malware removal tool, but, to my surprise, nothing showed up. Then I started rifling through the “My Documents” directory. Voila! I found the three “decrypt instructions” that get put in every directory that gets infected. (These are files that Crypto loads on to infected machines and servers, telling victims where to send their money, etc. But they are text files — not harmful in and of themselves.) At this point, I just shook my head.

When I’d performed the original cleanup, and every cleanup I have done since then, I did NOT remove these files. When I’d done the scans for the malware and deleted the malware itself, I’d assumed that those files were part of it and would get removed, as well. With the scan coming back clean and the data restored, I’d sent them on their merry way. But those files are not malware and obviously would not show up on the scans.

Moral of the story, ALL those files need to be deleted or they will pop up from time to time, with 1 of the 3 being an HTML file. Once you have scanned and cleaned up the malware, do a search of the C drive and every other data drive for *decrypt and find/delete all the decrypt instruction files. In this case I made a wrongful assumption that caused widespread panic.

However, sometimes you just have to learn as you go. ;)

If you need help from truly experienced techs, give us a call at 888-244-1748. We treat your technology as though it’s our own.

Tech tips for techs: Potential fix for errors when setting Global Admin rights in O365

Standard

 

In this TechTip I want to cover an error that we ran across while helping a customer resolve some strange error messages in Office 365.

The situation: Customer has several hundred users DirSync’ed to Office 365 from on-prem AD. Due to the size of their on-prem implementation, they’ve enlisted the help of another third-party vendor to assist with migrating their email over to the 365 platform. After the user accounts have been created, one of the users wants to be set as a Global Admin – but in the process of doing so they encounter an error that will not allow them to set ANY roles from within MOP.

The error: “You can’t edit the user’s role on this page because they have one or more partner-managed roles…”

The solution: “Partner-managed” roles didn’t make a whole lot of sense. This was something we’d never seen before. Scouring through the Active Users list yielded two accounts that were created by the third-party vendor — one of which was a cloud-only user and designated as a Global Admin. Knowing this was the case, we started combing through the available roles in the ECP, but nothing there was yielding a smoking gun.

Now we turn to Powershell…

The cmdlet Get-MsolRole will list the ObjectID, Name, and Description of all the baked-in roles that are available in 365 to be assigned to users. Your mileage may vary, depending on who you have your 365 offering through and how customized things are, but here’s the list I got back when running it against this tenant:

14-0814_1

It’s a short list, so it didn’t make sense for me to write a ForEach loop to iterate through it. We manually copy-pasted each ObjectID into the Get-MsolRoleMember cmdlet to see if the user in question was a member of any of them. Lo and behold… we found him in the first one!

14-0814_2

As a test, we opted to remove him from the Exchange Service Administrator role. The Remove-MsolRoleMember cmdlet requires you to provide the ObjectID of the user you wish to remove, so make sure that you re-run the Get-MsolRoleMember -RoleObjectID | fl command to grab the ID of the user you’re having a problem with. Once armed with this information, remove the user with the following command:

Remove-MsolRoleMember -RoleObjectID -RoleMemberObjectID

We then confirmed the removal by rerunning the Get-MsolRoleMember cmdlet for that role.

14-0814_3

Once done… we retried assigning that user Global Admin perms in MOP… and it worked!

 

Summary: The user’s membership in the Exchange Service Administrator MSOL role group was preventing us from assigning him Global Administrator permissions in MOP. By removing him from that group, we were then able to unlock that dropdown and add the permissions as expected.

Happy hunting!

 

Tech Tips for Techs – “Value cannot be null” error when creating rules in Office 365 OWA

Standard

 

In this TechTip, I want to discuss briefly an error message I’ve been asked about in Office 365 that led one of my peers on a wild goose chase.

The error, verbatim, reads: "Value cannot be null. Parameter name: identity"

This message pops up when trying to create a rule in OWA whereby you are trying to specify a group as either the sender or the recipient. So, while it would make sense to have a message from “sales@somecompany.com” go to an internal Distribution Group of “salesgroup@yourcompany.com,” the mechanism within Exchange Online that processes Transport Rules cannot enumerate the members of a DL and, as such, will not allow you to create a rule that forwards to a distro group. Unfortunately for us mere mortals, the message doesn’t make a whole lot of sense and doesn’t give you a whole lot to go on as to where to look next.

14-0805_1

 

The only workaround to this is to abide by the restrictions that Microsoft hath lain before us: list all of the destination emails individually.

14-0805_2

For larger groups of people this becomes a huge pain in the posterior. Yes, I’ve complained. No, they won’t do anything about it. Unfortunately, this is all by design, and there are no plans in place (that I’m aware of) to change it anytime soon.