Jump to content


ScriptingIT

Established Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by ScriptingIT

  1. So that was not a hard POC. Here is some untested autoit code you could run like this: CheckFileExists "C:\Program Files\My File\MyFile.exe","::Sensible name or task, where we are in the sequence, thanks for all the fish::" And you would get a centralised log showing where that machine is in the process and some time stamping etc. That's my kind of logging, really basic. Code would need error trapping, testing etc. AutoIT compiles to an EXE (password security). 10 lines of autoit to better SCCM/OSD logging (in terms of seeing useful info while machines build). Dim $Octecs[1] If $CmdLine[0] < 2 then MsgBox(0,"ERROR","You need to call " & @ScriptFullPath & " with " & chr(34) & "LOG ENTRY,FILE TO CHECK FOR" & chr(34)) $2Log = $CmdLine[1] $2CheckExists = $CmdLine[2] DriveMapAdd ( "Z:", "\\server\share",0, "domain\user", "password") If FileExists($2CheckExists) Then FileWriteLine("Z:\Logs\" & @IPAddress1 & "_" & @ComputerName & ".txt","Checking for file:" & $2CheckExists & @CRLF & $2Log & @CRLF & " ERROR:File does exit") Else FileWriteLine("Z:\Logs\" & @IPAddress1 & "_" & @ComputerName & ".txt",$2Log & @CRLF & " SUCCESS:File does NOT exit") EndIf
  2. In the end it was just easier to write a simpler deployment toolset and do our own logging so I'm not likely to do this if anyone else wants it. Anyweb feel free to just delete it. The issue here is not the tool (that is simple) its the translation table (that's to big a job for google half the time). Still there are some that could be captured and usefully shown with some set comments. Run a script at the end of critical task sequences that checks, maps a drive, and logs centrally to it would probably be better. Create the log as something like: COMPNAME_LASTUSER_IPSUBNET.txt. The computers name can be read from the local REG in PE (and last user or newest user profile dir etc). Mmmmm.
  3. I'm not sure which assumption to deal with first. We are a team with plenty of redundancy and our client get handover so most (not all) have internal people who can operate the solution. We are not re-inventing the wheel as the wheel you refer to is more a wheel template. That wheel template in fact does not do many things we (and our clients) need and therefore we created a wheel that does. Rather than buy just some software template you can by support from us and we can use and BDD and up light touch, SMS or SCCM. But if you want all some of the feature that solution does not have or cannot easily be adapted to give that ours can we have our toys also. Our toys can leverage any system and work with it or work on their own. You can leverage us and well run whatever it is or casually consult etc. I'm not selling mind we are nicely at capacity and taking on work as we can manage it (not much point marketing). Large companies tend to operate in small groups at the client coal face. We are just like one of those groups focused on SOE, packaging, deployment, etc. Clients tend to be 400 - 4000 space for us but really it makes little difference for deployment and even SOE (few more apps, big deal). I try not to get owned by a solution mind. I'm not sure if I'm being difficult or if you are unreasonably focused one a single technology when the outcomes of SOE and its management are more diverse than one solution can hope to offer (unless you can touch the dev team, have them on contract and order up some new 'toys for less'). Oh and don't get me started on the logging of all those systems, where SCCM stores packages by default, how slow the interfaces are, etc, etc, etc. I thought in fact your troubleshooting page (just for your reference one) was a poster child for how bad logging and troubleshooting MDT/SCCM/WDS etc really are (I know I've started). Still we design, build and manage them and keep them working. I forwarded to some of my team mentioning how good your guides are and how amusing that page is (we can all relate to it). More and more I am of a mind to replace it (SCCM) with something simple (I mean 4000 clients is not a lot and its not spread across the USA). I don't see anything simple so we created our own. It actually is simple. Thanks not an assumption, I've seen it and we work with both. It is all about client needs and not a specific technology. In this space that is the last of their troubles because they all work or they would not exist. Hope that explains it. ScriptingIT world famous in some parts of New Zealand.
  4. Did you read my post? We work a lot with SCCM and MDT, and as stated provide and manage solutions using both. When you get familiar enough with a product its common to start seeing it as really EASY. Its OK, I guess (they all are if run well). If you know your stuff and your clients though you can make life for them and yourself much simpler again. I'm not selling anything but I think I've enough experiance of the various technologies to still have an opinion. SCCM is just a framework, not the second coming. It is easy for us, we make it easier for our clients. Do you work for MS?
  5. All fixed now! Issue 1 is you cannot copy a WinPE3.0 ISO (generated using the WAIK) to say C:\MyIso.iso on a Windows XP machine and get that machine to reboot to that ISO (like you can with older WinPE2005 iso's using the process I described in another thread on this site). That is because the new ISO's are actually just wrappers that load a WIM into memory and the method we use actually loads the ISO into memory (hope that makes sense). The second issue is if I use an old PE iso that does work (I can boot from the local ISO as normal) but Diskpart and Format create a NTLDR boot loader. I tried running the later DiskPart but it does not work under PE2005. I tried Bootsect.exe but it gave errors also. In the end I copied the new PE3.0 System32 dir to a network share and from the PE2005 (which maps M: below that share) ran Bootsect.exe and it worked and set the bootloader to NT60. Now it all just works again. What does this mean? It means I can deploy our system from SMS2003 or any deployment system and it can rebuild XP to Win7 remotely without having to pay for SCCM cals, add mac addresses to databases, set machines to PXE boot as the first option etc, etc. We are AutoIT lovers so from PE2005 (again booting to that ISO from the local C:\ in XP) like this: Map M from PE2005 RunWait(@Comspec & " /c " & "diskpart.exe /s M:\scripts\diskpart_pe.txt",@TempDir,@SW_HIDE) RunWait("cmd /c Format c: /fs:NTFS /v:""CDisk"" /Q /Y",@TempDir,@SW_HIDE) sleep(1000) RunWait("cmd /c m:\Tools\CDTools\PE32Dir\bootsect.exe /nt60 /f c: >> c:\temp\ScriptingIT\BootRect_Log.log","m:\Tools\CDTools\PE32Dir\bootsect") Run ImageX and drop down your Win7 Wim Copy down the drivers for that model (and hardware based installs etc) Inject them Update the XML Drop in some non-base optional apps etc Much as I like SCCM not all our clients have it or plans to have it but they want to deploy Windows 7. Even where we do have SCCM I still tend to use our system because its easier for all concerned (NZ not all clients have a SCCM expert about our stuff is really simple to drive). Also we can send driver zipped packs to clients they just pop them in a DIR and ZAMMO another supported model etc. We can still use WDS if needed and all that but we are free (insert manic laughter here) from CAL's and mystically knowing MAC addresses of new machines etc. Having said all that SCCM is still pretty cool and the guides here made is MUCH more useable for me (and I live in it at times and date back to BDD2.5). SO APPRECIATE the time you've spent! Makes me want to contribute more. If you have never booted XP from a local ISO check out the other thread it is really quite useful at times (or in our case all the time on various sites).
  6. This one has been entertaining me for days... We like to use our own systems for Windows 7 rather than SCCM/MDT for some clients as we add a lot of features and can hand it over with less training. Still there is an issue when rebuilding XP machines to Windows 7 (trying to do this the way we currently rebuild XP to XP). Like my other post on this site we set an XP machine to boot from a CD ISO then reboot and from the CD image drop down the WIM, provision/move the Comp AD account etc. Issue1: You cannot use a PE3.0 ISO to boot XP from the local ISO (the boot from local ISO loads the ISO into memory but 3.0 ISO actually contain the WIM which they then load to memory so that does not work) To solve this I just created a good old PE2005 ISO which maps to the netork and kicks off the process. I changed all the logging to a network share (as there is no ability to write to X: in PE 2005). Issue2: If I Diskpart and Format the disk in PE2005 then load my WIM and reboot it gives me "NTLDR is missing" as in the MBR is XP because we Diskpart with PE2005 even after dumping down our WIM. I noted that BCDEDIT seems to run fine from PE2005 so I did an export on a PE3.0 CD (post diskpart/format/wim drop) and tried to import that under PE2005 post diskpart/format/wim drop. It said "success" but still gave NTLDR missing. Any ideas on this one would be nice. What we tend to do is create a SMS job that sets the remote machine to boot from the local ISO then reboots it, the iso does the rest. Sadly here I either cannot boot the PE3.0 ISO this way or cannot format the disk to suite Win7. I did try running the later Diskpart under PE2005 but it does not want to run it (invalid 32bit application). Any ideas would be good or I'll post back once I crack it.
  7. So many good bits of info on this site. I'll try add at least a few things given I've received plenty. I work with a small team that creates our own build solutions or uses the various MS ones. We are all scripter's and create a mad range or desktop management things all the time. There is no deployment without packaging and scripting. In fact I think those two areas are primary. Then there is post deployment management and keeping an SOE in line with the fleet (lots of work in that space). We are big fans of the SOE process though and Windows 7 makes it Christmas for us! Better than the Y2K scam (go Office Space). Where we have to work with SCCM and MDT natively I think it falls down around the logging most specifically (and pain in handing over to non-specialist BAU). There is no more one SCCM/OSD implementation than there is one Linux. MDT being so power shell scriptable is interesting. Fav technology, AutoIT - great tool I would hate to have to automate without it (HTA's/VBS are a true last resort for me now days) Powershell is a real upgrade to VBS.
  8. Autoit, Autoit, AUTOIT

    Now THAT is bad geek humor...

  9. I've been booting from local ISO's for years but I can never find instructions when I search for how to do it. Perhaps there are loads of these guides out there but just in case here is another. First up so I can find this again. Boot XP from local ISO Boot from iso stored locally Boot from c:\winpe.iso There is nothing like the smell of dirty old batch files in the morning... Extract the attached ZIP to C:\Temp\PELoaders Copy your ISO file to C:\ and call it winpe.iso NOTE: sadly this cannot be a PE3.0 iso as that just load a wim into memory and this process loads the iso into memory it just does not work If you do get this working let me know (you see the prob, this loads an iso into RAM which loads a WIM into RAM... earlier PE's and lots of others (bart) work fine You can run all this in Windows (I suggest a test machine incase you never manage to boot up again which is likely enough for a first go). Run these commands in a CMD (while live in Windows XP, again TEST MACHINE!) ATTRIB c:\ntldr -S -H -R copy c:\ntldr c:\ntldr.OS copy C:\Temp\PELoaders\ntldr.PE c:\ntldr ATTRIB c:\NTDETECT.COM -S -H -R copy c:\ntdetect.COM c:\ntdetect.OS copy C:\Temp\PELoaders\ntdetect.PE c:\ntdetect.com ATTRIB c:\winnt.sif -S -H -R del c:\winnt.sif copy C:\Temp\PELoaders\winnt.pe c:\winnt.sif ATTRIB c:\ntldr +S +H +R ATTRIB c:\NTDETECT.COM +S +H +R That Winnt.sif is a pre confirgured file looking like this: (so you iso needs to be c:\winpe.iso or you can change this file to suite - only x86 tested) [setupData] BootDevice = "ramdisk(0)" BootPath = "\i386\System32\" OsLoadOptions = "/noguiboot /fastdetect /minint /rdexportascd /rdpath=winpe.iso" Architecture = "i386" If at this point you realise this is not a test PC and I want to go home you can set everything back to booting from XP (or you do this in XP having just booted there using this method) and run ATTRIB c:\ntldr -S -H -R ATTRIB c:\NTDETECT.COM -S -H -R del c:\NTLDR del c:\NTDETECT.COM del c:\WINNT.SIF REN C:\NTLDR.OS NTLDR REN C:\NTDETECT.OS NTDETECT.COM ATTRIB c:\ntldr +S +H +R ATTRIB c:\NTDETECT.COM +S +H +R The boot files are Windows 2003sp1 files. Note the websites below show how do download an eval copy and extract them. Rebooting a remote machine to PE is useful. Add some tools like VNC server and you can then remote it and do AV scans, kick of deployments etc. Rebooting your own machine to PE locally is good to. This is part of our framework for 'Zero touch' for Windows XP. Now in Vista and 7 we can all boot from WIMS which is good when working with PE 3.0. After searching for winnt.sif and ISO I found some posts on this (seems everyone does it differently by the process here has worked for me for ages -only not with WinPE 3.0-). http://www.911cd.net/forums/index.php?showtopic=10445 http://www.911cd.net/forums/index.php?showtopic=10482 After seeing all the useful stuff from Anyweb it seemed time to try contribute something useful though this one might we widely known I can't find it myself. The ones above confuse me. PELoaders.zip
  10. The lastest SCCM/OSD is the best it has been but it still has a number or obvious issues and always has. I'm tempted to work on a few and thought I'd start here (might be already done after all). Problem 1 The worst problem IMO is logging for several reasons: It changes location all the time (well three times and it's not that hard to follow but it is still a pain in general) For every 10 lines of logs if you are really lucky one might be useful (so many repeats or overly verbose logging) Often the useful lines of log need to be decoded with google, and sites like this The logs are way to cryptic The logs do not include a lot of useful data (poor usersname or password for mapping drives say) The logs lack documentation (nice flow through guides for typical builds and lookups on everything) Tool 1 So I wondered if I could be motivated to write a tool that watches the logs (even as they move) and just translates some of the significant events. It might read from an ini so those events can be added over time and in phases. It could run at the different stages just watching the log with a "show logs" button maybe. Another tool might just read the events out of SCCM's System Status, deployments advert, just flow through logs for a single machine. These logs are quite useful but I find viewing them could be a lot better (but then there might already be better ways). Anyone interested or has done or seen something similar?
  11. I really just signed in to say thanks for sharing all that effort. I've read loads of your posts now and followed various guides. Makes me think I should be contributing more also. I might give that more of a go here. So thanks again and really well done.
  12. I think I've seen that before but I don't remember the details. There are some very good SCCM deployment guides here and the MDT documentation has a pretty decent quick start guide for SCCM deployments. I think that issue could be a number of things and you need to go through the guide and check all your settings (or start over). Otherwise you need more details. Did it ever work (if not recreate with guide) if so when does the error occur. Can you attach the log files (log locations in the guides). Good luck.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.