I’ve recently been trying to get a DS18B20 working with the Raspberry Pi, and although its well documented around the internet I ran into a bit of an issue where mine was always returning t=85000.
Although alot of people claims this is wiring (which could be the case) for me it was actually to do with how it was reading the value in the kernel module.
Originally in modules I had:
As it turned out, there’s a problem with the pullup (http://www.raspberrypi.org/forum/viewtopic.php?f=37&t=48588) where the below resolved the problem:
Been looking for something like this in a while to test newly setup or existing SMTP setups for simple server notification or business applications e.g. SharePoint, as it saves you having to install telnet or putty in order to send a quick test email to make sure its not getting blocked somewhere i.e. spam:
## Update ##
Just found out there’s an actual powershell Cmdlet for this: Send-MailMessage!
$msg = new-object Net.Mail.MailMessage
#Creating SMTP server object
$smtp = new-object Net.Mail.SmtpClient($smtpServer)
$msg.From = "fromID@xxxx.com"
$msg.subject = "My Subject"
$msg.body = "This is the email Body."
Thanks to SharePoint and Others for the basics!
Randomly came across Star Wars trace route, which is both funny and impressive,
Perform the following (windows):
tracert /h 254 obiwan.scrye.net
If like me you have a few secure hops before the internet keep waiting, it will eventual start hopping about and returning star wars style scrolling text… strange but true!
After the correct updates have finally been released last week (Exchange 2010 SP3 and Exchange 2013 CU1) it was time to get some Guinea Pigs… sorry, “Test Users” migrated over to Exchange 2013.
Some of the very small mailboxes were fine, but when it came to a real users mailbox the progressed appeared awfully slow. After taking a look at the log, I found it was full of:
The job is currently stalled due to ‘Content Indexing’ lagging behind on resource ‘CiAgeOfLastNotification()’
The message is a little misleading as it appeared that the content indexing wasn’t lagging at all, it was plain not working and showing as failed for the mailbox database.
After many reboots and diagnostics I still couldn’t figure this out, so I turned to google and finally after digging quite a bit I found the answer.
Please be aware that you will find this issue is most commonly talked about in reference to DAG groups replicating, but its a similar issue with migrations.
The answer was thanks to Bright Murewanhema on the technet forums (link), who contacted Microsoft Support for the resolution.
It appears that there’s a bug in Exchange 2013 RTM (which isn’t fixed by CU1 it appears) which causes the Exchange 2013 to not setup all the groups needed in Active Directory. The one in particular is called “ContentSubmitters”. You need to:
- Create the group yourself manually in Active Directory (I created in the existing exchange groups OU)
- Change the security on the group (not the members!) to allow “Administrators” and “NetworkService” accounts “Full Control”.
- Restart “Microsoft Exchange Search” on your mailbox server(s)
- Restart “Microsoft Exchange Search Host Controller” on your mailbox server(s)
After you have completed the above you should notice the mailbox databases content index status change to “Healthy” instead of “Failed”, and your migrations will start to transfer at a much more bearable rate.
I’ve been migrating classic mode SharePoint 2010 sites to claims sites for a while now, so much that I even have a script to do it for me. However, for some reason I have never come across the problem I encountered today.
The documentation on converting a classic mode web application to a claims based application I though was pretty solid on technet. Today I came across a strange issue where the site collection administrator was getting access denied in odd locations… or locations I thought were odd because SharePoint hadn’t security trimmed the links as I thought it would if access really was denied.
Turns out there is a small paragraph at the very bottom of the article which essentially points out “don’t forget to update your super user/reader properties!”… which I did! Not sure why I haven’t come across this until now but hope this helps others with the same issue.
The below PowerShell should help you out in fixing the issue:
$wa = Get-SPWebApplication -Identity <web app url>
$wa.Properties[" portalsuperuseraccount"] = "i:0#.w|<super user account in domainlogin format>"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|<super reader account in domainlogin format"
Came across and issue during the deployment of Office Web Apps 2013 when hooking up with SharePoint which caused some confusion.
Error messages from the web apps when activating through SharePoint documents:
Word Document : "Sorry, there was a problem and we can't open this document. If this happens again, try opening the document in Microsoft Word."
Excel Document: "We couldn't find the file you wanted. It's possible the file was renamed, moved or deleted"
PowerPoint: "Sorry, we ran into a problem. Please try again"
One Note:"Sorry, you don't have permission to edit this notebook."
It appears the issue was related to Office Web Apps having been deployed on HTTPS while SharePoint was on HTTP.
This is mentioned in the tech net documentation but it wasn’t very clear as it appeared to be the opposite way around, but the resolution is to allow SharePoint to use OAuth authentication over http instead of https (thanks to Imp44 for the solution at TechNet Forums )
The solution is to run the following on a SharePoint 2013 Server:
$config = (Get-SPSecurityTokenServiceConfig)
$config.AllowOAuthOverHttp = $true
If your trying to setup or change the configuration of SharePoint on a development machines which has Office 2013 install you may encounter some strange errors relating to types such as:
Failed to call GetTypes on assembly Microsoft.Office.InfoPath.Server, Version=184.108.40.206, Culture=neutral, PublicKeyToken=71e9bce111e9429c. Could not load file or assembly ‘Microsoft.Office.InfoPath, Version=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.
This is related to the way in which SharePoint is loading certain assemblies and struggles with the new assembly for InfoPath. Thanks to Hermanote for the workaround which is to remove the InfoPath feature from office only, and the error goes away.