Deploy MSI-package from GPO

To deploy msi package to from GPO.

1. Create GPO DeployPackage

a. User Configuration>Policies>Software Settings>Software Installation

b. Create new package, choose msi to deploy. Must be located on a shared folder that has read permissions for authenticated users (to include all domain computers).

c. Choose Published

d. Choose newly created package, Change Deployment>Deployment Type to Assigned and Check Deployment options>Install this application at logon

2. Deploy this GPO to an OU where the User object is located.

3. GPUpdate /force on both server and client.

4. If all works, the client will notice the policy and request a restart.

5. Package should deploy as soon as logged in.

Autodiscover pains in my side.

Problem: When setting up Outlook 2007 on a Server 2003 R2 a certificate error is shown every time Outlook starts. Exchange server is 2013 and Autodiscovery is pretty much mandatory.

Cannot connect to proxy server. Error code 10.

Symptom:s

Certificate error is shown at startup.

In the Outlook Anywhere settings, the proxyserver settings is set to the internal servername, like myserver.mydomain.local instead of the external mail.mydomain.com. The certificate is set to the external name so its no wonder Outlook complains.

When we alter the name in Outlook Anywhere settings the Proxyerror disappears. Though after restarting outlook once or twice, the settings returns.

Now the issue here is that these settings are only incorrect if the server (or computer) is a member of the domain. If a external Outlook puts up a user, everything looks fine in the Outlook Anywhere settings.

Cause:

Then looking for autodiscover settings, Outlook always looks to the domains SCP before the dns.

Now this can be amended by changing the parameters of cmdlet set-outlookprovider

Like : set-outlookprovider expr –server mail.mydomain.com –certprincipalname msstd:mail.mydomain.com and then restarting both mailserver and clientcomputer.

People usually solve the problem when doing that, but not in my case. I blame a very old server that probably upgraded Office one time to many.

Solution:

In my case I had to completely bypass the Active Directory to fool the Terminal Server to look towards the DNS, where everything worked dandy.

These are the magic settings.

Navigate to HKEY_CURRENT_USER\Software\Microsoft\Office\12.0 14.0 for Outlook 2010\Outlook\AutoDiscover and create these DWORD

"PreferLocalXML"=dword:0
"ExcludeHttpRedirect"=dword:0
"ExcludeHttpsAutodiscoverDomain"=dword:0
"ExcludeHttpsRootDomain"=dword:1
"ExcludeScpLookup"=dword:1 (forces Outlook to exclude SCP object check)
"ExcludeSrvLookup"=dword:1
"ExcludeSrvRecord"=dword:1

All cred for the fix goes to hosting.intermedia.net link below. Still pasting it here just in case they drop it.

On a side note, I also installed a brand new Server 2008 R2 with Outlook 2010 and didn’t see the issue there at all. So either something broke or Outlook 2007/Server 2003 bugged out.

References:

http://blogs.technet.com/b/umutg/archive/2011/01/31/all-about-set-outlookprovider.aspx

http://ilantz.com/2009/06/18/prevent-outlook-anywhere-aka-rpc-over-http-from-being-automaticly-configured-in-exchange-2007-with-autodiscover/

https://hosting.intermedia.net/support/kb/default.asp?id=2445

Trust Relationship between this workstation and primary domain failed

Symptom: When trying to login to the domain with a Windows 7 computer the following message is displayed “The trust relationship between this workstation and primary domain failed”.

Cause: Has the computer been out of sync with domain for some reason the domain computer password might have been expired. Check for trouble with dns or network errors.

Solution:

1. Log on to the Windows 7 computer with a local account
2. Go to system properties and choose Network ID
3. Go through the questions, yes its a domain and so on. Give a valid domain account that has the right to add computers to the domain. Normal user account works for default domains if not locked down.
4. Restart

Other solutions is to remove the computer from the domain. First on the local computer and then from the domain controller. Above solution, which is new for Windows7, is far more effecient though.

Error when creating user

Problem: Get error when trying to create a new user in Server 2008 AD.

Keywords: Active Directory Domain Services Windows cannot set the password for the admin because: Error 0x800708c5

kind of cryptic isn’t it?

Solution: Password wasn’t complex enough. Added a big letter and it worked fine. Still not the best errormessage.