Open up a command prompt on any machine in the domain and execute the following command:
NET GROUP "GROUP NAME" /DOMAINAt this point, you should see the list of users in correspond group.
Recently, we had a drive in our main machine at home fail and of course we didn't backup anything. As hardware on the drive itself failed, we were unable to run any recovery tools to revive anything off the drive. Fortunately, much of what was on the machine was on a different drive, except for my iTunes library. Luckily, we had recently synchronized one of our iPod's to the machine and we were able to recover almost the entire iTunes library from the device (cheap backup device eh? :P).
At this point your tunes should automatically be populating back into iTunes. iTunes will automatically copy the files from your desktop over to iTunes and properly place them inside your My Music folder. Just note that doing this process requires double the amount of space on your hard drive temporarily while iTunes copies the files from your desktop, but once all files have been copied, you can safely remove the folder on your desktop and resync your iPod to iTunes.
This morning I woke up to a nice ADFS issue which prompted Outlook to keep prompting for my credentials and my phone to prevent connectivity to Office 365. Since we are federated and sign-in was not working, I tried logging into Office 365 via the web. When trying to sign in to Office 365's webmail or portal, I was greeted by the following error:
Sorry, but we're having trouble signing you in.
Please try again in a few minutes. If this doesn't work, you might want to contact your admin and report the following error: 80041317.
Additionally, inside of event viewer on my ADFS server (not the proxy), I was seeing the following events:
Event ID: 111
The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/IssueAdditional Data
Exception details:
System.Security.Cryptography.CryptographicException: MSIS3135: The signature is not valid. The data may have been tampered with.
at Microsoft.IdentityServer.Service.Tokens.MSISRsaSignatureCookieTransform.Decode(Byte[] encoded)
at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound)
at Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ReadToken(XmlReader reader)
at Microsoft.IdentityModel.Tokens.SecurityTokenElement.ReadSecurityToken(XmlElement securityTokenXml, SecurityTokenHandlerCollection securityTokenHandlers)
at Microsoft.IdentityModel.Tokens.SecurityTokenElement.GetSecurityToken()
at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService.GetOnBehalfOfPrincipal(RequestSecurityToken request, IClaimsPrincipal callerPrincipal)
at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService.BeginGetScope(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.BeginIssue(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.DispatchRequestAsyncResult..ctor(DispatchContext dispatchContext, AsyncCallback asyncCallback, Object asyncState)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginDispatchRequest(DispatchContext dispatchContext, AsyncCallback asyncCallback, Object asyncState)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult..ctor(WSTrustServiceContract contract, DispatchContext dispatchContext, MessageVersion messageVersion, WSTrustResponseSerializer responseSerializer, WSTrustSerializationContext serializationContext, AsyncCallback asyncCallback, Object asyncState)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginProcessCore(Message requestMessage, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace, AsyncCallback callback, Object state)Event ID: 184
A token request was received for a relying party identified by the key 'fed.mydomain.com:443/adfs/services/trust/2005/usernamemixed', but the request could not be fulfilled because the key does not identify any known relying party trust.
Key: fed.mydomain.com:443/adfs/services/trust/2005/usernamemixedThis request failed.
User Action
If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.Event ID: 371
Cannot find certificate to validate message/token signature obtained from claims provider.
Claims provider: http://fed.mydomain.com/adfs/services/trust
This request failed.
User Action
Check that Claim Provider Trust configuration is up to date.
After a long conversation with Microsoft, the end result was somehow federation between Microsoft and our ADFS servers was severed. Here is how we fixed it.
Symptom: When logging into the Lync 2013 on an Android or iOS device, you receive the following error:
This version of Lync has been blocked by your system administrator. Please check for updates or contact your Lync support team.
Solution: This error is caused by not running the latest version of Lync Server 2013. Make sure you have at least the February Cumulative Update 1 patch applied to your server. Without this patch, the Lync client will not be able to login.
You can grab a copy of the patch from: http://www.microsoft.com/en-us/download/details.aspx?id=36820
Details on how to install the patch can be found here: http://support.microsoft.com/kb/2809243
Recently, I purchased a Ford Explorer and for whatever reason the keyless entry code was not bundled with the owner's manual nor is it listed when you type the VIN number into Ford's website and browse the vehicle's installed accessories.
Luckily, rather than bringing the vehicle back into the dealership, there is a way to lookup the default entry code. On the fuse box, the car has a label with a 5 digit code (sometimes followed by a single letter).
Next question is, where is the fuse box? Interestingly, there are two on the explorer. The first one is under the hood, on the right side inside of a "black box". The second one is in the typical spot underneath the steering wheel on the driver side (if anyone has an explorer in Europe and it has the steering wheel on the right side of the car, you should let me know if the fuse box is on the side with the steering wheel or still on the left side by what would be the passenger :P). Oddly enough, at a quick glance I couldn't find the fuse box as it was hidden by a piece of plastic. Luckily, if you can grab a flashlight and stick your head underneath the steering wheel far enough, you should be able to see the sticker, otherwise you will have the pull the hex screw off and remove the plastic guard.
For whatever reason, this isn't inside the owners manual, so hopefully this helps someone else with their explorer 🙂
Symptom: When signing into Lync from a Lync 2013 client, you receive the following error message:
Can't Sign in to Lync -- You didn't get signed in. It might be your sign-in address or logon credentials, so try those again. If that doesn't work, contact your support team.
Solution:
This error is caused by Microsoft's new Licensing model for Office. Since each office product is now linked to a user, you have to be very careful on how you deploy your office suite. To fix this error, you will have to remove the key to Office 365, outlined in this KB article (http://support.microsoft.com/kb/2745026), uninstall Office 365 Professional Plus, and then reinstall the suite to activate it with the user's Office 365 credentials. Similarly, I would suggest reconsidering your deployment process using one of the following methods to prevent this issue with new users.
You can have the user download the latest version by having them log into the Office 365 portal, select Download software under resources, and then selecting the latest version of Office 365 Professional Plus. Once the Office suite has been installed, have them activate the software using their credentials.
Alternately (this is more of the enterprise approach), you can deploy Office 365 Professional Plus using the Click-to-Run deployment method covered in one of my other posts (Deploying Office 2013 Professional Plus from Office365 Offline). Once the suite has been deployed, make sure that you activate the Office 365 suite using the user's credentials rather than your administrator ones.
Most articles are saying that Skype federation is now available and "you're good to go with federation enabled". The problem though is you are more than likely missing the "Skype" option when you select Add a contact not in my organization and you may need to enable PIC provisioning for Skype. This guide will go through enabling PIC federation through Office 365 and bringing back the Skype icon to the Lync client.
NOTE: This guide assumes you have configured your edge servers and have verified federation to other partners works.
Here is what my Lync client looked like before following the instructions below:
Example: If someone's email was [email protected], the entry would be bob(contoso.com)@msn.com
When setting up Lync-to-Skype federation for the first time, I was seeing the following symptom. Lync users could see the Skype user Offline, the Skype user could not add the Lync user as it would not pull the directory, and IMs would not work because the users had not accepted each other. Doing a log on the front end server, resulted with the following error message as well:
TL_INFO(TF_PROTOCOL) [0]1838.0B20::06/05/2013-14:36:41.206.00008d15 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2420.idx(196))[506561689] $$begin_record
Trace-Correlation-Id: 506561689
Instance-Id: B0B5F
Direction: incoming
Peer: myedgepool.mydomain.local:5061
Message-Type: response
SIP/2.0 480 temporary unavailable
Start-Line: SIP/2.0 480 temporary unavailable
FROM: "Jack Stromberg"<sip:[email protected]>;tag=0f6bccf745;epid=1aadaf98be
TO: <sip:person(hotmail.com)@msn.com>;tag=qwemztox
CALL-ID: a0b5bb30381640c08b30ee2bda403905
CSEQ: 1 INVITE
Via: SIP/2.0/TLS 192.168.169.221:53811;branch=z9hG4bK6DC1D74D.F39C6D8A52E04898;branched=FALSE;ms-received-port=53811;ms-received-cid=718100,SIP/2.0/TLS 192.168.170.142:50017;ms-received-port=50017;ms-received-cid=208A00
CONTENT-LENGTH: 0
ms-diagnostics: 1035;reason="Previous hop public IM provider did not report diagnostic information";Domain="msn.com";PeerServer="federation.messenger.msn.com";source="sip.mydomain.com"
ms-diagnostics-public: 1035;reason="Previous hop public IM provider did not report diagnostic information";Domain="msn.com";PeerServer="federation.messenger.msn.com"
$$end_record
Findings: Doing some research, the 480 temporary unavailable error with 1035;reason="Previous hop public IM provider did not report diagnostic information" means that there are federation issues. Since I know I enabled PIC Federation through Office 365 and federation worked to other partners (hotmail users for example), I assumed this was an issue with the PIC configuration.
Solution: According to a technet article recently posted (http://community.office365.com/en-us/blogs/office_365_technical_blog/archive/2013/06/01/troubleshooting-lync-skype-connectivity.aspx) if you are having issues federating to Skype, you may have to toggle the Public IM Connectivity mode switch in your Office 365 Lync portal. If you are a small business user, you are almost gaurenteed to be affected by the upgrade to Office 365 2013. If you are an enterprise business, it appears you should be fine, but in my case, I still saw issues connecting under an underprise account.
Additionally, it turns out I needed to submit a request to the old PIC provisioning crew at Microsoft in another scenario. Once they enabled federation to Skype, I was able to go on my merry way. You can start the request process here (their website can be quite frustrating... I couldn't get half the pages to load and ended up sending them an email): https://pic.lync.com/provision/Logon/Logon.aspx?rret=https%3a%2f%2fpic.lync.com%2fprovision%2fAgreementNumber.aspx%2f
Symptom: You receive the following errors in Event Viewer after installing the February Cumulative Update 1 for Lync Server 2013.
The database being used by Group Pickup is not the appropriate version.
Event ID: 31059
The database is not the correct version:
Connection: Data Source=sqlserver.mydomain.local;Initial Catalog=cpsdyn;Integrated Security=True
Expected... SchemaVersion: 1, SprocVersion: 1, UpgradeVersion: 2
Actual... SchemaVersion: 0, SprocVersion: 0, UpgradeVersion: 0
Cause: The database has not been upgraded.
Resolution:
Upgrade the database to CU1.
Event ID: 31055
There was a problem communicating with the Group Pickup backend database.There were problems accessing SQL server:
Connection: Data Source=sqlserver.mydomain.local;Initial Catalog=cpsdyn;Integrated Security=True
Message: The EXECUTE permission was denied on the object 'DbpGetVersionSchema', database 'cpsdyn', schema 'dbo'.
Error code: -2146232060
Error number: 229
Cause: This may be caused by connectivity issues with the backend database.
Resolution:
Check if SQL backend is running and accepts connections from Group Pickup.
Solution:
When installing Cumulative Update 1 for Lync Server 2013 from the following KB article http://support.microsoft.com/kb/2809243, make sure you follow the last step to update the backend database. To finish the steps, execute the following command via the Lync Server 2013 PowerShell prompt.
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn frontendserver.fqdn -Verbose
If the Lync Server 2013 Enterprise Edition back end servers do not have SQL mirroring configured, run the following cmdlet to apply the changes:
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn sqlserver.fqdn -Verbose
See the following KB article if you have mirroring configured on your backend database servers.
As you have probably found out, Microsoft no longer provides a traditional installer for Microsoft Office 2013. Additionally, you also probably know that the installer they do provide sucks down the installation files on each PC via the internet, which takes forever to deploy and install Office in an enterprise environment. That being said, here is the solution on how to deploy Office 2013 in an Enterprise environment! 🙂
<Configuration>
<Add OfficeClientEdition="32" >
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
</Product>
</Add>
<Updates Enabled="TRUE" UpdatePath="" />
<Display Level="None" AcceptEULA="TRUE" />
<Logging Name="OfficeSetup.txt" Path="%temp%" />
</Configuration>
@echo off
pushd %~dp0
echo /******************************************
echo /* Installing Office 365
echo /******************************************
setup.exe /CONFIGURE configuration.xml
pauseHope this helps! If anyone finds a better solution, please let me know and I can update the guide 🙂
Notes:
Here is a link to what Product IDs are supported for deployment: http://support.microsoft.com/kb/2842297
When communicating to hosted companies in Office 365 from an On-Premise Lync environment, I had begun seeing the following symptoms:
Solution:
Interestingly enough, even though you have an On-Premise Lync environment, it appears that Office 365 will tie back to your account for some settings. In my case, I had not enabled federation to other PIC providers on Office 365.
To resolve the issue, please follow the steps below:
Wait a few minutes for the changes to take effect, exit out of your Lync client on your workstation, reopen and you should now be able to communicate to your federated partner.