Remote Desktop Sharing Does not Work on Ubuntu 14.04 LTS

Open terminal apply that command

$ pkill vino
$ export DISPLAY=:0.0
$ /usr/lib/vino/vino-server &
$ gsettings set org.gnome.Vino require-encryption false

Thats All

Veeam Backup Guest Processing Skipped Error.

When you try to backup your vms whit Veeam Backup Application-Aware Image Processing  you can get that error.

Guest processing skipped (check guest OS VSS state and integration components version)
Unable to create snapshot (Microsoft CSV Shadow Copy Provider) (mode: Crash consistent). Details: Guest processing skipped (check guest OS VSS state and integration components version)
Error: Guest processing skipped (check guest OS VSS state and integration components version)

Try that steps to solve that problem.

  

•   Make sure integration services are up to date

•   If 2012 guest inside 2008 R2 host: look on guest for application error with source: vmicvss and event id: 13. If present, make the following registry edit:          HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore\       DWORD: ScopeSnapshots       Value: 0 (if you cant see that registry key create manualy)

•  Check shadow storage on the guest (vssadmin list shadowstorage).  Ensure the For Volume: and Shadow Copy Storage Volume: are the same for all partitions.•  Check for dynamic disks inside the guest (not dynamic VHDs)   

• Install windows backup feature if it is not installed.

•   Ensure system reserved partition (if the OS has one) is not running low on space. This should have at least 40MB free. If it does not, please try to backup the system state with Windows Backup and verify if it functions.

• Go to the Backup Job Settings > Storage > Advanced > Hyper-V and deselect the "Take crash consistent backup instead of suspending VM" checkbox.Use that setting same as picture and run the job again. 
  
   

Active Windows 8.1 Client On existing windows Server 2012 KMS server

Windows 8.1 and Windows Server 2012 R2 are now officially available. We need to do something licenced our new product.

You'll need to obtain your Server Key Management Service (KMS) key from Microsoft’s Volume Licensing Service Center.

If you have KMS serever on your domain you need to install that  http://support.microsoft.com/kb/2885698  updates to your KMS server. Just install that and it need restart don  worry.

Installed that update your KMS server and enter your KEY whit that command:

 slmgr.vbs /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx


You can then see the stats on how many KMS clients are activated, as well as checking that you're ready for 8.1 and R2 with the command slmgr.vbs /dlv.

Installing SCOM 2012 agent on a non-domain workgroup Windows Server

READ FIRST!!!
Note: You can find original document at that site: http://marckean.wordpress.com/2012/07/19/installing-scom-2012-agent-on-a-non-domain-workgroup-windows-server-core-computer-using-the-command-line/

after read that document be carefull to set dmz agent server host file sample like that scomsrv.domainname.com be careful setting dmz agent primary dns suffix and netbios name it must be same whit sertificate name sample: dmzagent.domainname.com.

 

The following are the list of steps that I took to install the Operations Manager (OpsMgr) 2012 agent on a workgroup based Windows Server Core 2008 R2 computer using certificates and without using a gateway server. Sometimes you might have a few servers in a workgroup e.g. DMZ that need to be monitored, so the below are the exact steps I took with the help of this article from Microsoft http://support.microsoft.com/kb/947691 In fact, these steps for the certificate template, requesting certificates, adding certificates to the local computer store and using the momcertimport tool are all exactly the same for adding certificates to gateway servers (communication between gateway and management servers), also agents (communication between the agent and gateway servers). See this link from the Microsoft TechNet Library for firewall rules using port 5723. I am writing this from the perspective of the command line, so that it will work for GUI based and non-GUI servers.

The first thing you need to do is get the workgroup based computers/servers to trust your internal domain certificate authority/PKI. So you’ll need to download the certificate chain as a .p7b file, then import this into the Server Core workgroup server. This ensures that the workgroup server can fully trust your domain based certificate authority, so that later the workgroup Server Core workgroup server can successfully take part in the certificate exchange. I am assuming here that your Operations Manager server is in the same domain as the certificate authority.
Prior to starting, make sure you change the security for manual agent installs to Review new manual agent installations in pending management view. This setting can be found under Administration > Security.

1. Logon to the certificate authority issuing server http://<certificateserver>/certsrv or https://<certificateserver>/certsrv from a domain based computer in the same domain where your certificate authority lives.
2. Click Download a CA certificate, certificate chain, or URL
   
3. Select Base 64 and click on Download CA certificate chain
   
4. Save the .p7b file to a location on your computer.
5. Now you will need to give yourself access to the Server Core workgroup server from the same domain based computer that you are on. Open command prompt > type in cmdkey /add:<ServerName> /user:<UserName> /pass:<password> Where: ServerName is the name of the server running the Server Core installation, and UserName is the name of an administrator account in the format of <servername>\<username>.
6. Open the Microsoft Management Console (mmc.exe), click start > run > type mmc > click OK.
7. Click on File > Add/Remove Snap-in > click Certificates on the left > click Add > Click Computer Account > Another Computer. Here you type in the name of the Server Core workgroup computer, then click Finish. Click OK to the other box.
8. Expand the Certificates node > expand Trusted Root Certification Authorities
9. Right click on the Certificates folder > choose All Tasks > Import.
10. Browse to the .p7b file you created before > click next > click next > click Finish.

The next thing that you will need to do is create a certificate template. Do this on the certificate server.

1. Open Certificate Templates, Click Start > click Run > type mmc > click OK.
2. From the File menu, click Add/Remove Snap-in > click Add > under Add Standalone Snap-in, click Certificate templates > click Add > click Certification Authority > choose local computer > click Finish > click OK.
   This is what you will see:
   
3. Click Certificate Templates > right click Computer > select duplicate template. Select Windows Server 2003
4. On the General Tab type a name like ‘OpsMgrWorkGroup’
5. On the Request Handling > select Allow private key to be exported
6. Click the Subject name tab > click Supply in the Request option
7. On the Security Tab, Authenticated users, Domain Admins, Domain Computers and Enterprise Admins should have Enroll and Auto Enroll permissions.
8. Add the new template to the CA. Right click Certificate Templates > New > certificate template to issue > choose the template you just created
9. Verify that the new template appears in the details pane, and then verify that the Server Authentication entry and the Client Authentication entry appear under Intended Purpose.
10. Open command prompt > type in gpupdate /force > hit enter.

The next thing you will need to do is request and import a certificate for the Management Server and on the workgroup computer

1. Create a certificate request .inf file:
   
   For most non-domain workgroup computers, the CN= equals NetBIOS name. Example: Subject="CN=MyWorkGroupPC". However, this may not work and you might receive errors in the event log after you finish all these steps. In this case, look for Event ID: 20052 in the Operations Manager event Log on the agent machine.
   Event 20052
   The specified certificate could not be loaded because the Subject name on the certificate does not match the local computer name
   Certificate Subject Name: dc-au-hv-20
   Computer Name: DC-AU-HV-20.domain.local
   To make sure you enter the correct CN name for the certificate in the request file, you can do a ping -a 1.1.1.30 on the server using it’s IP address, this should return the correct CN name to use.
   And here’s the contents of the request file:
   [NewRequest]
   Subject="CN=<FQDN>"
   Exportable=TRUE
   KeyLength=2048
   KeySpec=1
   KeyUsage=0xf0
   MachineKeySet=TRUE
   [EnhancedKeyUsageExtension]
   OID=1.3.6.1.5.5.7.3.1
   OID=1.3.6.1.5.5.7.3.2
   
   Save as RequestConfig.inf
    
2. Convert the INF into a binary REQ file. Run the following command line to create BinaryRequest.req from RequestConfig.inf
   certreq -new -f RequestConfig.inf BinaryRequest.req
3. Now you will need to submit the request to your domain based certificate authority. Submit the binary request to the CA and retrieve the resulting certificate. Run the following command line to submit BinaryRequest.req to CorpCA
   
   1. From a domain based computer, logon to http://<certificateserver>/certsrv or https://<certificateserver>/certsrv > click Request a certificate.
      
      
   2. Click on Advanced certificate request
      
   3. Click on Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
      
   4. Paste the contents of the BinaryRequest.req file you created above into the box > select the OperationsManagerCert template > click Submit
      
   5. Retrieve the certificate. Select Base 64 encoded > click on Download certificate
      
      Download the certificate and save as NewCertificate.cer
      
4. Copy the NewCertificate.cer file to the workgroup computer > run the following command to install the certificate into the Local Computer Personal store
   certreq -accept NewCertificate.cer

 

Thanks to the following pages for the above information:

• http://support.microsoft.com/kb/947691
• http://blogs.technet.com/b/momteam/archive/2008/06/02/obtaining-certificates-for-ops-mgr.aspx
• http://www.bpmi.nl/blog/?p=1124
• http://skaraaslan.blogspot.com.au/2012/04/monitoring-non-domain-members-workgroup.html

Export the private key from the the management server and on the workgroup computer

1. Click Start, click Run, type cmd, and then press ENTER.
2. Type in certutil.exe -privatekey -exportpfx <Subject Name of certificate> <filename>.pfx nochain
3. Type in a password twice to confirm.

The next thing that you will need to do is manually install the agent on the workgroup computer 

1. The MOMAgent.msi agent can be found on the management server C:\Program Files\System Center 2012\Operations Manager\Server\AgentManagement\amd64. Make sure you have access to this directory from the Server Core workgroup server.
2. The following example shows a fresh installation of an agent and uses the Local System for the Action Account. When installing the agent on a computer that needs to connect to the gateway server, under Management Server, rather than specifying the name of your management server, specify the name of the gateway server. So you’ll need name resolution in the form of hosts files if no DNS works outside your organisation.
   msiexec.exe /i \\path\Directory\MOMAgent.msi USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=<MG_Name> MANAGEMENT_SERVER_DNS=<MSDNSName> ACTIONS_USE_COMPUTER_ACCOUNT=1 USE_MANUALLY_SPECIFIED_SETTINGS=1 SET_ACTIONS_ACCOUNT=1

Use the Momcertimport tool to import the certificate on each, management server and workgroup computer

The Momcertimport tool is used to enter the serial number of the specific certificate in the registry. You must follow these steps on the management server and on the workgroup computer. Make sure that the Operations Manager agent is installed on the workgroup computer. Otherwise, you will receive an error when you run the Momcertimport tool.

1. Click Start >click Run.
2. In the Open field, type cmd > click OK.
3. Type the following command, and then press ENTER:
   MOMCertImport.exe <filename>.pfx
   The MOMCertImport.exe tool can be found in the Support Tools folder of the Operations Manager installation media.
   
4. Restart the OpsMgr Health service (aka System Center Management). Don’t forget to do this on the management server and the workgroup computer.
   
   
   1. sc stop HealthService
   2. sc start HealthService

To uninstall the agent, should you need to, run the following command:

1. msiexec.exe /x <path>\MOMAgent.msi

How to create Anonymous Relay Send Connector in Exchange 2013

How Anonymous Relay works in Exchange 2013

This article is to provide you, the reader, the knowledge on how to properly create an Exchange 2013 Relay Connector.

In Exchange 2013, I am utilizing a multi-role server that has both the Client Access Server and Mailbox Server roles. We’ll want to head to the mail flow section in the Exchange Administration Center (EAC) that you can access by going to https://OWA.domain.com/ECP.

Once in this mail flow section, we’ll click the tab called receive connectors which will allow us to see all receive connectors that exist.

As you can see, there are connectors for FrontendTransport and connectors for HubTransport.  FrontEndTransport belongs to the Client Access Server Role and the HubTransport role belongs to the Mailbox Server role.

Let’s take a look at the “Default B-E15DAG1″ receive connector that belongs to the HubTransport role  as well as the “Default Frontend B-E15DAG1″ that belongs to the FrontendTransport role.

Taking a look at the “Default FrontEnd B-E15DAG1″, we can see that the connector listens on port 25 as we would expect.

Taking a look at the “Default B-E15DAG1″ receive connector, we can see it listens on port 2525 which is something we haven’t seen before.

All mail flow should come into the Frontend Transport which then delivers it to the appropriate mailbox server where the mailboxes exist.  On a multi-role server, these two roles cannot utilize the same ports as they are two different services.  What this means is, when creating a relay connector, this connector must be created on the Client Access Server role that owns the Frontend Transport because this service is the service that owns port 25.  If you try to create a receive connector on the Mailbox Server role that owns the HubTransport service, mail flow may work temporarily, but it will eventually fail due to both the FrontendTransport and HubTransport services fighting each other for port 25.  Obviously if the Client Access Server and Mailbox Server roles are on different servers, it’s not an issue.

To create our relay connector, we’ll choose the + symbol to create a new Receive Connector.

Give the connector a name and be sure to choose Frontend Transport and Custom. Click Next.

The default settings here are fine.  We want port 25 due to what I mentioned above. Click Next.

In the remote network settings, it is important to ensure that you remove 0.0.0.0-255.255.255.255.  We want to explicitly define what servers are allowed to relay to ensure our server does not turn into an open relay for everybody.  In my case, I am going to add 192.168.50.2 which may be a printer, custom application, etc…  But the server that owns 192.168.50.2 would need to relay.  Once this is done, click Finish.

Once the relay connector is created, open its properties, go to security, and make sure you check Anonymous Users.

So what really happens when you place a check mark in the Anonymous users group in the above screenshot?  A lot of people are afraid to place a checkmark in that box in fear that anonymous users will be able to relay off your Exchange Server.  This is NOT the case.

When you place a checkmark in that box, the following permissions are given to the Anonymous Logon group:

• Ms-Exch-SMTP-Submit
• Ms-Exch-SMTP-Accept-Any-Sender
• Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
• Ms-Exch-Accept-Headers-Routing

So, as you can see, there is no Ms-Exch-SMTP-Accept-Any-Recipient permission added by default.  Because of this, users will NOT be able to relay off your Exchange Server by default.

To activate Anonymous users to use this connector for relaying, you must issue the following command: Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

The command should be easy enough to read, but what it essentially does is retrieve the receive connector that you created, add a permission into Active Directory for the Anonymous Logon group, and assign that group the Ms-Exch-SMTP-Accept-Any-Recipient permission for that group on that connector.  Once this is done, any server IPs you added to the Remote Network settings will be allowed to relay off your server utilizing port 25.

Now you may be thinking, why should I create this new connector?  Well, Exchange will always look to see how specific you are on a connector.  So let’s say we have a SharePoint Server at 192.168.119.150.  We would create a relay connector and allow ONLY 192.168.119.150 to relay.  So when Exchange receives SMTP from an address of 192.168.119.150, it will see there are a few connectors.  One being the Default Receive Connector and one being the Relay Connector.  The Default Receive Connector allows connections from any IP Address while the Relay Connector only allows connections from 192.168.119.150.  Because you explicitly set the address on your Relay Connector, that is given higher preference in serving that SMTP connection from SharePoint and your SharePoint Server will now be able to relay off of Exchange (even though you can configure SharePoint to authenticate, but still just giving an example).

Now, for servers that will have a lot of relay traffic, there are some more steps you need to do on your Receive Connector.  If you see that you have mail flow issues where things periodically work with relaying and sometimes they don’t, it’s recommended to run the following commands on your Relay Connector.

Set-ReceiveConnector -identity “Relay Connector Name” -TarpitInterval 00:00:00

Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionTimeout 00:30:00

Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionInactivityTimeout 00:20:00

Set-ReceiveConnector -identity “Relay Connector Name” -MaxAcknowledgementDelay 00:00:00

Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnection 10000

Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPercentagePerSource 100

Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPerSource unlimited

So in my case, I would run the following command which would allow me to do Get-ReceiveConnector and pipe into Set-ReceiveConnector to make all the modifications in one command:

Get-ReceiveConnector -Identity “Relay Connector Name” | Set-ReceiveConnector -TarpitInterval 00:00:00 -ConnectionTimeout 00:30:00 -ConnectionInactivityTimeout 00:20:00 -MaxAcknowledgementDelay 00:00:00 -MaxInboundConnection 10000 -MaxInboundConnectionPercentagePerSource 100 -MaxInboundConnectionPerSource unlimited

If you are wondering what the default settings were, I ran the following to view the defaults before running Set-ReceiveConnector.

DPM 2012 Crash when open recovery tab

When you  install DPM 2012 on Windows 2012 server you can get that problem. Install DPM 2012 management agent Windows 2008 R2 computer or Windows 7 computer

To backup inconsistent databases, run a consistency check on the farm. (ID 3106)

You could verify how much data DPM is trying to back up by running the following command in an Administrator command prompt on the protected server:
C:\Windows\System32\wbadmin.exe start backup -allcritical -backuptarget:%1
(Just say "No" when it prompts to start the backup operation.)