This script will automate the process of service accounts creation in SharePoint 2010. The solution exists in 2 parts. The first part is a CSV file, called sp2010_service_accounts.csv, where you can specify the service accounts you need. The second part is a powershell script called SP_ServiceAccounts.ps1.

1) Download the zip file from here (http://tomvangaever.be/blog/powershell/ ... rShell.zip)

2) Extract the script to, for example, c:\yourname

3) Run powershell and navigate to c:\yourname


4) Execute SP_ServiceAccounts.ps1

- When you receive an error saying that you cannot execute the powershell script, please enter Set-ExecutionPolicy Unrestricted.The reason for this error is the security setting on your pc that does not allow you to execute a script. This is the so-called Execution Policy. By default, the Execution Policy is set to Restricted. This setting means that you may not run any PS1 script at all.

An overview of the policy levels:
Restricted: Individual cmdlets can run, but not saved Powershell scripts. This is the default setting.
AllSigned: Scripts can run, but must have a digital signature even if written on the local computer. Prompts you before running scripts from trusted publishers.
RemoteSigned: Scripts written on the local computer do not need a digital signature, but any script downloaded from outside (email, IM, Internet) must have a signature to execute.
Unrestricted: Any script can run, but scripts downloaded from outside will run with a warning.

- The first parameter you need to specify is the OU you would like to create for the service accounts.
(for example: SP Service Accounts)

- The second parameter is the location of the csv file containing the service accounts.
(for example: c:\yourname\sp2010_service_accounts.csv)



5) When everything went right, the service accounts specified in the CSV file are created for you in 5 seconds.


Job's done!

PS: I've included the service accounts in the CSV file for you ;)

While creating a Visual Studio 2010 VSIX , I'm using reflection to inspect the project dll. While using this assembly's types, my addin creates other files in the solution... This enables me to generate code that would take me hours to write (I love this sentence!). But in this scenario I learned some things about reflector I haven't had any issues with before, probably because it wasn't in this particular scenario... I hope you didn't knew it already ;)

1) Load an assembly that is also deployed in the Global Assembly Cache or GAC
When you use the Assembly.LoadFrom(string assemblyFile) method, you'll notice that the assembly you load is not the assembly in the folder that you specified in your parameter, but it is the assembly that you have installed in your GAC. naturally when the assembly is not installed in the GAC, there is no issue ;)




But what if, like in my case, you would like to analyze a Type in a dll... And you would like to analyze the dll in the project bin folder and not the one in the GAC? Consider this quote regarding reflection:
You can load a disk-based assembly with the same identity as one in the GAC. If you tried this with LoadFrom or LoadFile, the GAC assembly is ALWAYS loaded.

In my case this is the not the behaviour I need, what I need is the Assembly.ReflectionOnlyLoad and the Assembly.ReflectionOnlyLoadFrom methods. It is important to know that these 2 methods only reflect the assembly, which basically means that you cannot load them... if you do try to load them, you'll receive an InvalidOperationException.

The solution?
By using the Assembly.ReflectionOnlyLoadFrom() method you are always analyzing/inspecting the dll you specified as a parameter.




2)the assembly dll is locked after using Assembly.ReflectionOnlyLoadFrom()
It seems that by using the LoadFrom methods will put a lock on the dll, this is not interesting for me because I would like to change the dll by building in in Visual Studio and then inspect it again... The resolution seems rather to easy!





The solution?
Assembly assembly = Assembly.ReflectionOnlyLoad(System.IO.File.ReadAllBytes(dlllocation));

More information:
http://msdn.microsoft.com/en-us/library ... embly.aspx
http://msdn.microsoft.com/en-us/library/0et80c7k.aspx
http://stackoverflow.com/questions/5701 ... ly-reflect
http://stackoverflow.com/questions/3058 ... ononlyload

Issue resolved, have a nice day!

The only way to do software development for SharePoint is really a Virtual Machine. Yes, with SharePoint 2010 you can install it on Windows 7 and Vista and with some hacking you can get SharePoint 2007 to run on Vista. However I’m talking about real development for real men (and women!). For that we setup virtual machines (VMs) and usually run the whole SharePoint stack on it (SharePoint, SQL Server, Visual Studio, SharePoint Designer, Office, etc.).

One of the key advantages of running in a VM is the ability to run your SharePoint server as a domain controller (or at least connected to one) where you have ultimate control over it. This allows you to practice safe installs, spin up an environment with exactly the same OUs as your production environment, use the same account names, etc. all without having to peeve off your friendly neighbourhood domain admin.

The last piece of the isolated puzzle is getting mail working.

This is the part where Bil Simser explains in detail (I like those posts, in detail), check it out!

Read Article

The wonderful news continues, yesterday I received word I passes the IT PRO certifications for SharePoint... today I received the message that I also passed the 70-573 exam called TS: Microsoft SharePoint 2010, Application Development

I didn't had the chance to complete the 4th SharePoint 2010 exam, but this is certainly on my task list ;)

As with any evolving product, there are false ceilings set due to people’s experiences with previous versions. The initial core features/capabilities for SharePoint were targeted to provide out-of-the-box features that made the product easy to use and administer for team sites and portals.

The product was extensible from the beginning, but it was not architected for the mainstream developer. This focus has changed over the years and there are very compelling reasons that product companies should consider SharePoint in their technology roadmaps.
The ability to leverage the rich features of SharePoint technologies is reason enough to consider SharePoint as a web
development platform.

Another key reason to consider either building on top of SharePoint or having a connection strategy with SharePoint is market opportunities that come from being associated with this popular platform (over 100 million licenses of SharePoint have been sold).

The purpose of this white paper is to address the perceived limitations that typically cause product
companies to discount SharePoint when determining a technology roadmap for their products.

This white paper will dive into some of the features of the platform, including how a company could build a better product faster and take advantage of the rapid adoption and increased market interest in SharePoint as a platform. Also described in this paper are the Connect, Extend, and Build On strategies and the advantages of each approach.


Download here