After painfully recovering a Calendar last week for a user, they were no longer able to set 'Custom' permissions for their Calendar. All the Free/Busy options had disappeared from the panel completely. The solution turned out to be running outlook.exe /ResetFolders Only that fixed all the odd permission issues on the Calendar.
Monday, July 25, 2011
Wednesday, July 20, 2011
Silent installs and MDT 2010
The initial rollout of MDT was well received by the rest of my IT department but as with all things the new toy eventually led to new requests for changes. At the top of the list was to make the application installs silent or hands-free. It didn't take long to discover that there was no silver bullet to fix that problem. There are multiple installer programs, differences between .msi implementations, secret flags, and in some cases a matter of hunting down hidden alternate downloads of application installers. In this post I'm going to describe how I streamlined my testing and at the bottom I'll list all the install flags that I'm using currently.
The first you'll need a good testing platform. I recommend either a Hyper-V or VMWare VM so you can just do snapshots and then restore the state back after each test.
Next you'll want to create a Custom Task in MDT 2010 that will just run 1 application. You'll be able to manually run this task from your virtual machine while inside windows. Otherwise you'd have wait for the whole OS install, etc each time you want to test a new command line syntax. To get to the Task you just go to your deployment share, Scripts folder and run litetouch.vbs.
"\\yourservername\deployment$\Scripts\LiteTouch.vbs"

Once there, click the Command Line section and you'll see what options you have for non-interactive or silent installs. There are multiple entries for most of them as the method sometimes changes with newer versions of the software or some users just like different options to be selected instead. If you make good use of virtual machine snapshots you'll save yourself tons of time testing these out.
WHENEVER possible, use the noreboot or suppress reboot. MDT hates it when apps reboot by themselves. Just set the reboot flag under the application properties in MDT instead.
For some applications you'll have to download special versions of the installer and for others you may have to do an msi extraction first. Below you'll find my list of applications that I use and what flags work for me.
7-zip 64 bit
msiexec /i 7z465-x64.msi /quiet
windirstat
windirstat1_1_2_setup.exe /S
CutePDF (made a batch file)
ECHO Installing converter
converter.exe /auto
ECHO Installing cutepdf
cutewriter.exe /silent
Malware Bytes
mbam-setup.exe /SP- /SILENT /NOCANCEL
Symantec Endpoint protection 11.0.6
Just create a self-installing image using the Centralized admin console
Microsoft Windows Live Messenger
WLSetup-web.exe /q /NOToolbarCEIP /NOhomepage /Nolaunch /nosearch /AppSelect:Photo,Mail,Messenger
Microsoft .net 4.0 framework
dotNetFx40_Full_x86_x64.exe /passive /norestart
Microsoft Office 2007/2010
Just use the customization tool - http://technet.microsoft.com/en-us/library/cc179097.aspx
Adobe Acrobat X Reader
AdbeRdr1000_en_US.exe /sAll /msi /norestart ALLUSERS=1 EULA_ACCEPT=YES
VMWare Player 3.0
msiexec /i "vmware player.msi" REBOOT=ReallySuppress DESKTOP_SHORTCUT=0 QUICKLAUNCH_SHORTCUT=0 /qn
Microsoft Visual Studio 2010 (recommend doing an application bundle with SP1)
setup\setup.exe /q /norestart
Microsoft Visual Studio 2010 SP1 (recommend doing an application bundle with SP1)
setup /q /norestart
Roxio Creator 10.3
setup.exe /qn Reboot=ReallySuppress
SQL Server 2008 R2
Let the GUI build out an unattended file for you.
Then use this syntax:
setup /CONFIGURATIONFILE=CompanyInstallSettingsR2.ini /INDICATEPROGRESS /SAPWD="password"
Microsoft TMG 2010 Firewall Client
msiexec /i ms_fwc.msi SERVER_NAME_OR_IP=yourTMGServer ENABLE_AUTO_DETECT=1 REFRESH_WEB_PROXY=1 /qn /L*v c:\fwc_inst.log
SnagIT 9.x
Build out a batch file
snagit.exe USERNAME="INSERT USER NAME HERE" TSC_SOFTWARE_KEY="INSERT KEY HERE" TSC_LICENSEMODE="Full" /quiet
That's all folks! Good luck.
Tuesday, June 21, 2011
Lync 2010 SIPPROXY_E_CONNECTION_EXTERNAL_INTERNET_ACCESS_DISABLED
So after following 3 guides and one book I can now connect to my Lync 2010 server remotely through TMG 2010. The nifty error in the title there was rather fun to get rid of. You'd think that just toggling a setting that says enable remote user access would be the end of it. The final hitch that got me was that all the guides I found for setting up an Edge server have you export/import the configuration BEFORE you assign a global access policy and the Access Edge Configuration. I just assumed that once they'd partnered up, all updates would just magically sync by themselves. I found out through trial and error that if you make changes after you've deployed your Edge server then you need to go back in and re-import the configuration. Here's how to sync them up again:
1. Export out the current configuration from your internal Lync 2010 server.
Export-CsConfiguration -filename c:\temp\yourfilename.zip
2. Import the current configuration onto your Edge server using that file.
Import-CsConfiguration -filename c:\temp\yourfilename.zip -LocalStore
Thursday, June 9, 2011
TMG 2010, android 3.0, and the google market
Now this one was driving me up the wall. One of our users has a new Iconia Tablet and wasn't able to use the Android market at all while behind my firewall but worked fine everywhere else. I did a trace with TMG and there were no errors, all outgoing connections looked fine. So I went ahead and threw on Network Monitor onto the firewall so I could see where it was going. I noticed that 74.125.227.4 kept popping up which resolves to android.clients.google.com. I added that to the Web Browser tab for the proxy and then let the settings kick in and it fixed the problem. So I'm guessing that there's some issue with the TMG proxy and the google market.
Well, that didn't fully knock it out of the park. Apparently it also tries an outbound TCP 5228 which I also had to add to the protocol list for my users.
Wednesday, May 25, 2011
Powershell script to change UPN suffix of an existing user
One of the things that I really hate about using UPN suffixes in Active Directory is that it doesn't sort the list Alphabetically. So if you've got a server with say 50 UPN suffixes you have to scroll through all of them. So here's a script my colleague wrote to do a quick changeover. (Watch out for wrapped text if you copy and paste this out. Some of the write host commands are too long for blogspot.)
#####################################################################
#
# Script to change UPN of an AD User
#
# Co-authored by Gnawgnu
#
# Last edited 5/25/11
#
####################################################################
Import-Module ActiveDirectory
Function ChangeUPN ($samName2, $upnName2) {
#test for existence
$samDead = get-aduser $samName2
if(!$samDead) {
write-Host "Account not found"
} else {
$fullupn = $samName2 + "@" + $upnName2
write-host ""
write-host "Changing to $fullupn now" -foregroundcolor green
write-host ""
set-ADUser $samName2 -userprincipalname $fullupn
}
}
if ($Args.Count -lt 2) {
write-host ""
write-host "=================== You Failed ===================" -foregroundcolor red
write-host ""
write-host "Enter in user logon name AND and email suffix" -foregroundcolor red
write-host ""
write-host " Example: ChangeUPN.ps1 myusername test.local" -foregroundcolor yellow
write-host " Do NOT include the @ symbol" -foregroundcolor yellow
write-host ""
write-host "Try again" -foregroundcolor red
write-host ""
} else {
$samName = $Args[0]
$upnName = $Args[1]
write-host "Congrats on following directions"
write-host ""
write-host "Changing UPN for user $samName to be $upnName" -foregroundcolor green
write-host ""
write-host "Please allow up to 5 minutes for AD to refresh"
ChangeUPN $samName $upnName
}
Tuesday, March 15, 2011
monad.exe backup exec 2010 and failed exchange GRT backups
I got this one from a colleague this week who'd been struggling with a backup exec issue. GRT enabled exchange backups suddenly stopped working and the event logs on the exchange server kept showing a monad.exe 13.0.4164.0 failure followed by beremote crashing. Symantec released a hotfix this week that appears to fix it:
Thursday, February 17, 2011
Dell WebCam and WebEx problem
I recently had fun trying to get the integrated Dell WebCam on an E6410 to work with WebEx. Turns out that by default the software runs in Capture mode. At the bottom right if you change the drop down to IM mode, then WebEx can use the camera.
Monday, February 14, 2011
How to Set Up AD FS 2.0 to SSO to Salesforce using SAML 2.0
Project:
Set up Microsoft AD FS 2.0 on my Windows 2008 R2 Active Directory to allow my users to authenticate to Salesforce.com using their domain accounts using SAML 2.0. We'll be using Federated Authentication and not delegated authentication which requires you to code your own web service.
Introduction:
On paper, Single Sign-On (SSO) looks fairly simple and very logical and can lull you into a false sense of confidence. In practice, it requires a lot of planning, preparation, and some knowledge of sessions, authentication infrastructure, packet capture, encryption, and sometimes alcohol. If you're more of an administrator and less of a programmer, you'll also notice how closely the lines between the two are blurred when you work with these products. There's a lot of articles out there on using several 3rd party IDPs to SSO to the force.com suite but I had trouble finding stuff for AD FS 2.0
Prerequisites:
A working Active Directory, preferably 2008 or higher.
A server or virtual machine that can run AD FS 2.0, preferably 2008 or higher and joined to your domain.
An active Salesforce.com account. They do recommend using a developer account for the initial setup and testing of SSO.
A valid SSL certificate that's trusted on the Internet. I use a wildcard certificate personally.
A DNS host record for your new AD FS. For this tutorial, I'm using samlportal.example.com
If you're using a firewall (which you should) between your AD FS and the internet, then you'll need to publish inbound SSL to it. Preferably with no authentication required.
If you want to set up a AD FS Proxy in a DMZ, then a second server or virtual machine will be required. For that, you'll need port 443 open from the proxy AD FS to the internal AD FS and 443 open from the internet to your proxy AD FS. The proxy server does NOT have to be domain joined.
Federation Service Name notes:
Try to avoid using your internal DNS AD name, and do not name it the same as the server's host name. You really want this name to be unique. This name will also have to be resolvable on the Internet since you'll need an A record for it and an SSL certificate.
Setup:
First download AD FS 2.0 to your server.
Install the IIS role on your server.
Add your SSL certificate to IIS (IIS manager under Server Certificates) and bind it to 443.
Test the server to make sure SSL is working.
Only AFTER you have the SSL settings right, then proceed to install AD FS 2.0
Install AD FS 2.0 and choose the "Federation Server" option.
Then run the AD FS 2.0 Federation Server Configuration Wizard to Create a new Federation Service.
Now you have a decision point, if you've only got a handful of users you can just do a stand-alone install. If you plan on having hundreds to thousands of users on this, then you can set up a Farm which will allow you to have multiple servers. Note: This option uses Windows Internal database (aka SQL express effectively). If you want to utilize an existing SQL DB server, you have to install using the command line.
Next the installer will detect your SSL certificate. If it doesn't, something's wrong with your IIS configurations.
Click Next
It'll install now and give you a list of success/failures. Warnings are generally not a problem and often occur if you're reinstalling AD FS.
If you get an SPN registration error, you'll have to update it manually from the command line. Substitute the following using your federation id and the account you're running AD FS as a service under.
setspn -S host//samlportal.example.com ADFSserviceAcctName
After that's done, go into the AD FS 2.0 console, click Service, right click on Service and choose Edit Federation Service Properties.


Next go into your salesforce account, then Setup, then on the left Security Controls, then Single Sign-On settings. This next bit of configuration came from a forum post from "Da G Man" on the thread: http://social.msdn.microsoft.com/Forums/en/Geneva/thread/2fc66b27-966c-49e5-891e-6e7e404e001d (Yeah, forums are great).
Choose Edit, then change the SAML drop down to 2.0.
For the Issuer, enter in your Federation Service Identifier. In this example, it was http://samlportal.example.com/adfs/services/trust
And yes, that is http and not https. And it is CASE-Senstive.
Choose User ID Type: Assertion contains User's salesforce.com username
Choose User ID Location: User ID is an Attribute element.
Enter Attribute Name: mail
Then click Save.
Next on your AD FS server, go to Trust Relationships>Relying Party Trusts and add a new Relying Party Trust.
Under Data Source, choose Import data about the relying party from a file and choose your file that you downloaded from Salesforce.
Name it something. (This name will display on your user's login portal)
Choose the Permit all users option.
Click Next.
Click Finish.
Right-click on the relying party trust and choose Edit Claim Rules.
Name the claim something.
Choose Active Directory for the Attribute Store.
Choose E-mail Addresses for the LDAP Attribute and type in mail for the Outgoing claim Type.
Now make sure you have a user in salesforce whose username field matches the primary email address of a user in your active directory. Also make sure that this user is not an Administrator in Salesforce as by policy SSO supposedly doesn't work for those.
Now it's time to test. After much searching I figured out what URL I was supposed to use and I've provided it below:
(yes, it is https and it has no bearing on your Federation service identifier being http)

At this point the IDPInitiatedSignOn page should have loaded. If it didn't, then you've got a configuration issue. Otherwise you should be at a page that gives you the option to either log on or log on and go to salesforce in one step.
So now you've (hopefully) got the IDP initiated sign on part working! At some point you'll notice that you're still able to log in with your old login and password if you go to the salesforce site directly. Apparently the only way to fix that is to first switch to using their My Domain feature.
Once you're provisioned your domain, then log off, then back on using your new domain URL which will be in the form of yourdomain.my.salesforce.com
After that's set up, if you go back into Single Sign-On Settings and enter in an Identity Provider Login URL and Save your site will now force all visitors to use Single Sign-On. Now the URL is tricky and I found one that works but I can't promise it's the 'correct' one but it works and that'll do for now.
The above URL is comprised of my my SSO provider's IDP signon page plus a '?" then loginToRp= and then your salesforce domain name.
For further troubleshooting you may want to install a header capture program like Fiddler to help you debug your setup.
Feel free to comment if you have any corrections or suggestions and I'll integrate them into this howto.
Additional Notes:
There's a fun bug in Firefox where it'll prompt you endlessly for credentials. Workaround is here:
If you want to provide the Identity Provider Logout URL you can use:
https://samlportal.example.com/adfs/ls/?wa=wsignout1.0 (yeah, it's a legacy method but seems to work)
Useful Links:
Good forum post that answers the my domain SSO question.
Changing Federation Service Name.
Subscribe to:
Posts (Atom)