Archivo

Archivo para la categoría ‘English Articles’

GuruXP Repository – March 2013

miércoles, 3 de abril de 2013 Sin comentarios
Categories: English Articles, Repositories Tags:

Restrict access to Exchange Online

martes, 26 de marzo de 2013 Sin comentarios

 

Cambiar-idioma-esp

ExchangeOnline

Some days ago, i found myself with a client petition, where they wanted to restrict the access to Exchange Online on a few users only to be able to access their e-mail via OWA. Well after i bit of investigation i found out how to do it via PowerShell, so here are some CmdLets to do so:

Of course, we need to have our environment ready for Office365 administration via PowerShell.

Once we have our system logged on to Office365 via PowerShell with our admin credentials, we can run the following commands as needed:

Disable OWA Access

set-CASmailbox user@domain.com -OWAEnabled $false

Enable OWA Access

set-CASmailbox user@domain.com -OWAEnabled $false

Disable IMAP Access

set-CASMailbox user@domain.com -ImapEnabled $false

Enable IMAP Access

set-CASMailbox user@domain.com -ImapEnabled $true

Disable POP Access

set-CASMailbox user@domain.com -PopEnabled $false

Enable POP Access

set-CASMailbox user@domain.com -PopEnabled $true

Disable Exchange ActiveSync use with mobile devices

set-CASMailbox user@domain.com -ActiveSyncEnabled $false

Enable Exchange ActiveSync use with mobile devices

set-CASMailbox user@domain.com -ActiveSyncEnabled $true

Disable SMS for all the organization

Set-OwaMailboxPolicy Default -TextMessagingEnabled $false

Enable SMS for all the organization

Set-OwaMailboxPolicy Default -TextMessagingEnabled $true

Disable Outlook Access

Set-CASmailbox user@domain.com –mapienabled $false

Enable Outlook Access

Set-CASmailbox user@domain.com –mapienabled $true

 

I hope you find them useful…

Inactive mailboxes on Exchange Online

domingo, 24 de marzo de 2013 Sin comentarios

Cambiar-idioma-esp

 

o365

Today we´ll cover something new in Office365 Exchange Online and Exchange 2013, it´s about Inactive Mailboxes. These mailboxes let you keep the contents of a mailbox you´re about to delete indefinitely without the need of a license.

The only requisites we must have in order to get this feature working are:

  • Have an Exchange Online Plan 2 or the Online Archive feature.
  • Activate the «In-Place Hold» function on every mailbox before the deletion. If we´ve already deleted the mailbox without activating this function, we can bring it back during 30 days from it´s deletion and actívate the function.

So, how do we do it?.

  1. First of all will be create/convert a mailbox into inactive. To do so, we must define an undefined retention or a time based retention:
    1. Via GUI:
      1. Access the Exchange Administration Console (EAC)
      2. Click on Compliance Management
      3. Click on the “In-Place eDiscovery & Hold“ tab.
      4. Click on the “+” button.
      5. Give a name and a description to the retention policy and click on “next
      6. Select the mailboxes you want to include on the retention policyand click on “next
      7. Click once again on “next” and mark the checkbox that says “place content matching….” and select the time we want to hold the content, indefinitely or by days.
      8. Click on “Finish
    2. Via PowerShell:
      1. Prepare our environment to run with PowerShell
      2. Run the following command:New-MailboxSearch “Retention_Name” -SourceMailboxes user@domain.com -InPlaceHoldEnabled $true
  2. The second thing will be to delete the mailbox we want to retain via the Office365 Administration portal or with the PowerShell command “Remove-Mailbox”

Well, we now have our mailbox archived and hold indefinitely (or the days we want to), so how do we access that content?, via PowerShell:

  1. Run the following command on PowerShell:

    New-MailboxSearch “Search_Name” -SourceMailboxes “Source_mailbox” -TargetMailbox “Discovery Search Mailbox” -IncludeUnsearchableItems -LogLevel Full

We´ll get the results on our discovery mailbox

Until next time!

Solution to the winmail.dat and Exchange Online Problem

sábado, 23 de marzo de 2013 Sin comentarios

 

Cambiar-idioma-esp

ExchangeOnline

Sometimes when we send an E-mail to a recipient with an attachment (i.e, a pdf file), and that recipient uses Outlook Express as an e-mail client, instead of receiving the pdf file, it will receive a file named winmail.dat as an attachment. Well stop looking no more on the recipients server, antivirus software or even the antispam because the problem is in your Exchange server and it can be easily solved.

This situation is due to the encapsulation format that the Exchange servers uses by default and that Microsoft is propietary named TNEF or  Transport Neutral Encapsulation Format. This encapsulates the MAPI properties of the message.

When we send the message with an attachment, and leaves our Exchange Organization but it arrives on an E-mail client that is not compatible with Outlook´s rich text format, the attachment will be replaced for another one named  winmail.dat.

To avoid this situation, whe must simply login to our Office365 subscription using PowerShell with our admin credentials (of course we must have our environment ready for it), and run the following command:

Set-RemoteDomain Default -TNEFEnabled $false

This way all the outgoing messages sent outside our organization wont be using this encapsulation format. Hope many of you find it useful.

GuruXP Repository – February 2013

miércoles, 13 de marzo de 2013 Sin comentarios

Add or Remove Office365 users via PowerShell

miércoles, 13 de marzo de 2013 Sin comentarios

Cambiar-idioma-esp

 

logo-powershell

In order to Add or Remove Office365 users using PowerShell, we must hace our environment ready to use with PowerShell and connect with Office365.

Once this is done, we can proceed…

Add Users:

We must have available licenses on our subscription if we want to assign one, if this is not the case, then we must Access to our Office365 Administration portal and buy some.

  • Log in to our office365 using powershell.
  • Run the following command to create the user:

New-MsolUser -UserPrincipalName a.lopez@contoso.com -DisplayName “Antonio Lopez – Contoso Ltd.” -FirstName “Antonio” -LastName “Lopez

  • Specify the location of the user (in this case, Spain)

Set-MSOLUser –UserPrincipalName a.lopez@contoso.com –UsageLocation ES

  • Assign a license to the recently created user with the following Cmdlet

Set-MsolUserLicense -UserPrincipalName a.lopez@contoso.com -AddLicenses “tenantname:AccountSKUId”

Where “tenantname” will be in our case “contoso” and “AccountSKUId” will be the plan we wish to assign. The available AccountSKUId are:

K1: SHAREPOINTDESKLESS EXCHANGE_S_DESKLESS

K2: SHAREPOINTWAC SHAREPOINTDESKLESS EXCHANGE_S_DESKLESS

P1: MCOLITE SHAREPOINTLITE EXCHANGE_L_STANDARD

E1: MCOSTANDARD SHAREPOINTSTANDARD EXCHANGE_S_STANDARD

E3: OFFICESUBSCRIPTION MCOSTANDARD SHAREPOINTWAC SHAREPOINTENTERPRISE EXCHANGE_S_ENTERPRISE

E4: OFFICESUBSCRIPTION MCOSTANDARD SHAREPOINTWAC SHAREPOINTENTERPRISE EXCHANGE_S_ENTERPRISE

A2: SHAREPOINTWAC_EDU MCOSTANDARD SHAREPOINTSTANDARD_EDU EXCHANGE_S_STANDARD

Besides, we can run the following cmdlet to determine the AccountSKUId used on our Office365

Get-MsolAccountSku | Format-Table AccountSkuId, SkuPartNumber

Note: if we want to do a license upgrade to a selected user, we must first remove the assigned license and then assign the new one.

To remove a license to a user, run the following:

Set-MsolUserLicense -UserPrincipalName a.lopez@contoso.com -RemoveLicenses “tenantname:AccountSKUId

Remove a User:

Simply run the following Cmdlet:

Remove-MsolUser -UserPrincipalName a.lopez@contoso.com

This will move the user to the «Deleted Mailboxes» área because it´s not a HardDelete…

Until next post….

Import and Export Wi-Fi profiles on Windows 7 and Windows 8

sábado, 16 de febrero de 2013 Sin comentarios

 

Cambiar-idioma-esp

In order to import and export Wi-Fi profiles on a Windows Vista, Windows 7 or Windows 8 PC, we must make use of the Net Shell (Netsh), so we must run from an admin command line the command «netsh».

Once we´re inside the net Shell, run the following commands:

-To get the Wireless networks saved on our PC:

wlan show profiles

-To export the saved wireless networks:

wlan export profile

-To export one single wireless network saved on our pc:

netsh wlan export profile name=”network name” folder=”destination folder”

-To import one single wireless network:

netsh wlan add profile filename=”network name.xml”

The wireless networks that are exported, are in XML format, so if what we want is to add another network to the system as a deployment, we can get one of the exported files as a pattern to follow and modify the desired values.

Hope you find this info useful.

Import/Export VPN Profiles on Windows 7 and Windows 8

viernes, 15 de febrero de 2013 Sin comentarios

When we migrate our machine to another one, or re-format to install a new fresh Windows, we get all type of info like docs, favs, pst´s, ost´s. dekstop, etc… But there´s something really useful for the IT Pros and that´s the VPN Profiles.

This post can make us save time when we got more than one VPN to configure on our PC, and best of all it´s a really easy process, so we can include it as a must have on every migration process.

In order to import or export these profiles on Windows 7 and Windows 8 based pcs, we must nav to the following path:

 %userprofile%\AppData\Roaming\Microsoft\Network\Connections\Pbk

and copy the file named “rasphone.pbk”, this file contains all the VPN and RAS (if we still use them) profiles that we have created under our session.
In order to import these profiles back on to the new system, simply nav to the same path and replace the previous copied file and restart the system. Once this is done we must have all the connections back that we used to have on the previous system.
Simple and easy, but useful :)

GuruXP Repository – January 2013

viernes, 1 de febrero de 2013 Sin comentarios

SendAs and SendOnBehalfOf with Exchange Online via PowerShell

viernes, 11 de enero de 2013 Sin comentarios

 

Cambiar-idioma-esp

Sometimes, there are situations where recieving department messages is not sufficient via distribution groups, but also exists the need to answer them or even write new ones using the department address and not from the personal assigned mailbox… For that, Microsoft has brought some Cmdlets that we can use with PowerShell: SendAs and SendOnBehalfOf.

So lets begin telling the differences between them:

SendAs: It let us send messages using the department address (i.e: administration@contoso.com) from the personal assigned mailbox (i.e: user@contoso.com , this way, the destinatary will recieve the sent message with the department name as the sender.

This method is really useful in situations where we have two personal addresses inside the organization (i.e: an alias) and don´t want to spend on another license to use with a new mailbox…

Also, if what we want is to set a rule where the personal assigned mailbox cannot send messages outside the organization except if the message is sent using the department address, this method is the solution for it.

SendOnBehalfOf: It let us send messages On Behalf Of the company department (i.e: user@contoso.com on behalf of administration@contoso.com), this way the destinatary will recieve the message with the sender as “User on behalf of department» (i.e: John Summer on behalf of Contoso Administration Department).

This method is really useful when what we want is to let know the destinatary who sent the message inside the company department, or who did the reply, and all the department recieve the reply when the destinatary does it.

Well once this is all cleared, lets explain the process for doing this with both methods. Lets keep in mind that to do so, we must have our PowerShell environment prepared for administrating Office365 services

 

SendAs

  • For use with one specific user:

$LIveCred = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LIveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

Add-RecipientPermission department@contoso.com -AccessRights SendAs -Trustee user@contoso.com -Confirm:$false

  • For use with Security or Distribution Groups:

Add-RecipientPermission department@contoso.com -AccessRights SendAs -Trustee group@contoso.com -Confirm:$false

  • Viewing the SendAs permissions applied on the organization:

Get-RecipientPermission | where {($_.Trustee -ne ‘nt authority\self’) -and ($_.Trustee -ne ‘null sid’)}

  • Viewing the SendAs permissions applied to a specific user:

Get-RecipientPermission –Trustee User@contoso.com

  • Revoke SendAs permissions to a specific user:

Remove-RecipientPermission department@contoso.com -AccessRights SendAs –Trustee user@contoso.com

 

SendOnBehalfOf

  • For use with one specific user:

$LIveCred = Get-Credential$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LIveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

Set-DistributionGroup Department@contoso.com -GrantSendOnBehalfTo user@contoso.com

The only problem with this code is that when we run it again for another user, this last execution will replace the previous one (always with the same department) and will be the only one to send on behalf of the department. To avoid this problem here´s a workarround:

$a = Get-DistributionGroup department@contoso.com

$b = Get-User user@contoso.com

$a.GrantSendOnBehalfTo += $b.DistinguishedName

Set-DistributionGroup department@contoso.com -GrantSendOnBehalfTo $a.GrantSendOnBehalfTo

Get-DistributionGroup department@contoso.com | fl name,grant* > List_SendOnBehalfOf_assigned_permissions_on_department.txt

This way we can add users to Send On Behalf Of in nested mode, but instead it will require to run this code each time we want to add another user and the administration task will be some lines more to achieve our goal…

  • For use with Distribution and Security Groups: This is the best option, it´ll sabe us administration time, avoiding unnecessary lines in our PowerShell each time a new user enters a department…

$a = Get-DistributionGroup department@contoso.com

$b = Get-DistributionGroup «Distribution Group»

$a.GrantSendOnBehalfTo += $b.DistinguishedName

Set-DistributionGroup department@contoso.com -GrantSendOnBehalfTo $a.GrantSendOnBehalfTo

Get-DistributionGroup department@contoso.com | fl name,grant* > List_SendOnBehalfOf_assigned_permissions_on_department.txt

I´ve added the «> List_SendOnBehalfOf_assigned_permissions_on_department.txt» on the last line to know who has SendOnBehalfOf permissions inside the department and send it to whoever asks for it (i.e: our IT Manager)

Once this is done, the user will only have to specify the address from where he wants to send the message inside OWA or Microsoft Outlook.

In Microsoft Outlook (if the user doesn´t have more than one account configured) we must enable the «From:» field inside a new E-Mail – Options – From: (above «show fields») and then we can specify the address where we want to send the message from typing it after clicking in «Othe E-Mail address»

Inside OWA occurs the same thing, and we must proceed the same way to enable de From: field.